Reviewing files that changed from the base of the PR and between 992a94a and db4cd66.

• docs/architecture.svg is excluded by !**/*.svg
• docs/delegate.drawio.svg is excluded by !**/*.svg
• docs/delegate.svg is excluded by !**/*.svg
• docs/deposit.drawio.svg is excluded by !**/*.svg
• docs/deposit.svg is excluded by !**/*.svg
• docs/lst-flow.svg is excluded by !**/*.svg
• docs/withdraw.drawio.svg is excluded by !**/*.svg
• docs/withdraw.svg is excluded by !**/*.svg
• package-lock.json is excluded by !**/package-lock.json

• .env.example (1 hunks)
• .github/workflows/forge-ci.yml (3 hunks)
• README.md (3 hunks)
• docs/ClientChainGateway.md (6 hunks)
• docs/btc-staking-e2e-testing.md (9 hunks)
• docs/client-chain-contracts-design.md (7 hunks)
• docs/contract-governance.md (1 hunks)
• docs/contracts-owner-manual.md (1 hunks)
• docs/cross-chain-communication-model.md (2 hunks)
• docs/native_deposit_workflow.wsd (4 hunks)
• docs/reward-vault.md (6 hunks)
• docs/summary.md (1 hunks)
• foundry.toml (1 hunks)
• hardhat.config.js (1 hunks)
• package.json (2 hunks)
• script/10_DeployExocoreGatewayOnly.s.sol (0 hunks)
• script/10_DeployImuachainGatewayOnly.s.sol (1 hunks)
• script/11_SetPeers.s.sol (3 hunks)
• script/12_RedeployClientChainGateway.s.sol (3 hunks)
• script/13_DepositValidator.s.sol (2 hunks)
• script/14_CorrectBootstrapErrors.s.sol (3 hunks)
• script/15_DeploySafeMulstisigWallet.s.sol (2 hunks)
• script/16_UpgradeImuaCapsule.s.sol (2 hunks)
• script/17_WithdrawalValidator.s.sol (2 hunks)
• script/19_DeployFaucet.s.sol (2 hunks)
• script/1_Prerequisites.s.sol (2 hunks)
• script/20_DeployCreate3.s.sol (1 hunks)
• script/21_UpgradeImuachainGateway.s.sol (1 hunks)
• script/2_DeployBoth.s.sol (8 hunks)
• script/3_Setup.s.sol (3 hunks)
• script/4_Deposit.s.sol (3 hunks)
• script/5_Withdraw.s.sol (3 hunks)
• script/6_CreateImuaCapsule.s.sol (2 hunks)
• script/7_DeployBootstrap.s.sol (5 hunks)
• script/8_RegisterValidatorsAndDelegate.s.sol (4 hunks)
• script/9_ExtendBootstrapTime.s.sol (1 hunks)
• script/BaseScript.sol (5 hunks)
• script/compareLayouts.js (1 hunks)
• script/deployments/deployedContracts.json (1 hunks)
• script/deployments/deployedExocoreGatewayOnly.json (1 hunks)
• script/deployments/deployedMultisigWallets.json (1 hunks)
• script/deployments/prerequisiteContracts.json (1 hunks)
• script/deployments/testContracts.json (1 hunks)
• script/generate.mjs (17 hunks)
• script/hardhat/deploy-and-setup-utxogateway.script.js (3 hunks)
• script/integration/1_DeployBootstrap.s.sol (11 hunks)
• script/integration/2_VerifyDepositNST.s.sol (1 hunks)
• script/integration/BeaconOracle.sol (1 hunks)
• script/integration/NetworkConfig.sol (1 hunks)
• src/core/BaseRestakingController.sol (5 hunks)
• src/core/Bootstrap.sol (22 hunks)
• src/core/BootstrapLzReceiver.sol (2 hunks)
• src/core/ClientChainGateway.sol (3 hunks)
• src/core/ClientGatewayLzReceiver.sol (6 hunks)
• src/core/CombinedFaucet.sol (1 hunks)
• src/core/ImuaCapsule.sol (10 hunks)
• src/core/ImuachainGateway.sol (15 hunks)
• src/core/LSTRestakingController.sol (2 hunks)
• src/core/NativeRestakingController.sol (8 hunks)
• src/core/UTXOGateway.sol (20 hunks)
• src/core/Vault.sol (1 hunks)
• src/interfaces/IBaseRestakingController.sol (3 hunks)
• src/interfaces/ICustomProxyAdmin.sol (1 hunks)
• src/interfaces/IImuaCapsule.sol (2 hunks)
• src/interfaces/IImuachainGateway.sol (2 hunks)
• src/interfaces/ILSTRestakingController.sol (1 hunks)
• src/interfaces/INativeRestakingController.sol (3 hunks)
• src/interfaces/INetworkConfig.sol (1 hunks)
• src/interfaces/ITokenWhitelister.sol (1 hunks)
• src/interfaces/IValidatorRegistry.sol (4 hunks)
• src/interfaces/IVault.sol (1 hunks)
• src/interfaces/precompiles/IAssets.sol (6 hunks)
• src/interfaces/precompiles/IBech32.sol (1 hunks)
• src/interfaces/precompiles/IDelegation.sol (5 hunks)
• src/interfaces/precompiles/IReward.sol (1 hunks)
• src/libraries/ActionAttributes.sol (1 hunks)
• src/libraries/Errors.sol (6 hunks)
• src/libraries/ExocoreBytes.sol (0 hunks)
• src/libraries/ImuachainBytes.sol (1 hunks)
• src/libraries/NetworkConstants.sol (1 hunks)
• src/storage/BootstrapStorage.sol (15 hunks)
• src/storage/ClientChainGatewayStorage.sol (3 hunks)
• src/storage/GatewayStorage.sol (2 hunks)
• src/storage/ImuaCapsuleStorage.sol (3 hunks)
• src/storage/ImuachainGatewayStorage.sol (3 hunks)
• src/storage/UTXOGatewayStorage.sol (11 hunks)
• src/storage/VaultStorage.sol (1 hunks)
• src/utils/BeaconProxyBytecode.sol (1 hunks)
• src/utils/CustomProxyAdmin.sol (1 hunks)
• test/foundry/BootstrapDepositNST.t.sol (7 hunks)
• test/foundry/Delegation.t.sol (9 hunks)
• test/foundry/DepositThenDelegateTo.t.sol (12 hunks)
• test/foundry/DepositWithdrawPrincipal.t.sol (28 hunks)
• test/foundry/Governance.t.sol (4 hunks)
• test/foundry/ImuachainDeployer.t.sol (14 hunks)
• test/foundry/TvlLimits.t.sol (6 hunks)
• test/foundry/unit/Bootstrap.t.sol (46 hunks)
• test/foundry/unit/ClientChainGateway.t.sol (14 hunks)
• test/foundry/unit/ImuaCapsule.t.sol (16 hunks)
• test/foundry/unit/ImuachainGateway.t.sol (35 hunks)
• test/foundry/unit/UTXOGateway.t.sol (34 hunks)
• test/hardhat/integration/btc-stake-e2e.test.js (1 hunks)
• test/hardhat/integration/btc-stake.test.js (4 hunks)
• test/mocks/DelegationMock.sol (2 hunks)
• test/mocks/ImuachainGatewayMock.sol (15 hunks)
• test/mocks/NonShortCircuitEndpointV2Mock.sol (4 hunks)

• script/10_DeployExocoreGatewayOnly.s.sol
• src/libraries/ExocoreBytes.sol

• script/integration/BeaconOracle.sol
• src/interfaces/ICustomProxyAdmin.sol
• src/core/CombinedFaucet.sol
• script/integration/NetworkConfig.sol
• src/interfaces/IVault.sol
• src/libraries/NetworkConstants.sol
• src/interfaces/INetworkConfig.sol
• src/core/Vault.sol
• src/interfaces/ITokenWhitelister.sol
• docs/contract-governance.md
• src/interfaces/precompiles/IAssets.sol
• script/20_DeployCreate3.s.sol
• script/deployments/deployedMultisigWallets.json
• src/storage/VaultStorage.sol
• src/storage/ClientChainGatewayStorage.sol
• src/interfaces/precompiles/IReward.sol
• src/interfaces/IValidatorRegistry.sol
• src/utils/BeaconProxyBytecode.sol
• src/interfaces/precompiles/IDelegation.sol

script/21_UpgradeImuachainGateway.s.sol (2)

1-14: All imports and versioning look good.
No issues with the pragma version and imports here. Everything is consistent with OpenZeppelin’s ProxyAdmin usage and the LayerZero endpoint interface.

---

15-34: Consider verifying addresses from the JSON file.
The code checks that none of the addresses read from deployedContracts.json are zero, which is good. For added safety, you might want to verify these addresses belong to the intended contracts (e.g., checking that proxyAdmin indeed references a ProxyAdmin contract).

You could run a script to confirm storage layout consistency across old and new logic contracts, ensuring no overshadowed variables. Would you like me to help generate that?

script/5_Withdraw.s.sol (1)

1-1: No annotated code snippet was provided for review.
Cannot produce line-level review without the changed code.

script/4_Deposit.s.sol (7)

5-5: Import alignment is correct.
The import for IImuachainGateway is consistent with your broader rename.

---

38-44: Validate gateway addresses.
Successfully switching from Exocore to Imuachain references. Ensure these imuachainGateway and imuachainLzEndpoint address values are correct for all networks.

You can double-check that “.imuachain.imuachainGateway” and “.imuachain.lzEndpoint” in deployedContracts.json match your intended environment.

---

45-48: Conditional handling of precompile mocks.
Good approach for environment-specific logic. Confirm that _bindPrecompileMocks() aligns with the new Imuachain environment if implemented for tests or dev.

---

49-53: Clear comment for gas fee transfers.
Handing out gas fees to depositors, relayers, and gateway addresses is essential for local testing. This is a useful approach for test environment coverage.

---

52-52: Top-up of deposit tokens.
Line 52 specifically approves extra restake tokens. Double-check that the token address matches the environment’s minted supply.

---

54-57: Fork creation for Imuachain.
Fork-based approach will help ensure simulation is realistic. These lines look well integrated into your workflow.

---

80-91: Endpoint mock usage and bridging logic check.
Confirm lzReceive usage with the newly minted GUID is correct for your bridging scenario. The next nonce is read from imuachainGateway and then used in lzReceive; ensure the bridging flow remains consistent with your chain ID references.

You could run a specialized script to replay deposit flows across forks and confirm that the bridging messages succeed, if needed.

script/3_Setup.s.sol (4)

36-41: Validate gateway addresses and JSON entries.
You’re reading address values from the JSON, then immediately requiring that they not be empty. Ensure that the JSON keys match exactly and that there’s no risk of returning the zero address.

Would you like to run a script to confirm the JSON keys for ".imuachain.imuachainGateway" and ".imuachain.lzEndpoint" exist and aren’t empty in your deployedContracts.json?

---

45-48: Confirm usage of _topUpPlayer.
These _topUpPlayer calls are presumably for funding addresses with ether. Double-check that the addresses (owner.addr and imuachainGenesis) are valid in all environments and that the forks (clientChain, imuachain) match the intended chain IDs.

---

68-70: Check chain ID consistency in setPeer.
When linking gateways, ensure that imuachainChainId is the correct chain ID constant for Imuachain. A mismatch here could break cross-chain messaging.

---

125-140: Verify fee quoting and token whitelisting flow.
The code quotes a native fee via imuachainGateway.quote before calling addWhitelistToken. Confirm that these calls succeed on Imuachain, the expected fees are correct, and that partial failures are handled or retried.

src/core/NativeRestakingController.sol (2)

4-4: Import rename looks correct.
Replacing IExoCapsule with IImuaCapsule is consistent with the project rename. No further changes needed.

---

50-52: Check for capsule creation edge cases.
When a caller has no existing capsule, the code calls createImuaCapsule(). Ensure that external failures in createImuaCapsule() (e.g., if Create2.deploy reverts) are handled properly or revert the entire transaction as intended.

script/2_DeployBoth.s.sol (3)

66-66: Implementation constructor argument check.
Passing address(0) to new ImuaCapsule(address(0)) is presumably a placeholder because initialization happens later. Confirm that no crucial logic runs in the constructor that depends on this address.

---

117-146: Conditional Imuachain gateway deployment logic.
Both mock and non-mock logic paths appear to call initialize with owner.addr. Verify that owner.addr is correct for the Imuachain side, especially in local/test environments. Any mismatch here can cause permission or admin issues after deployment.

---

152-180: Serialized contract names updated.
Renaming exocoreContracts to imuachainContracts is aligned with the rebrand. Ensure that the consumer scripts or documentation referencing the old key name are also updated accordingly.

test/foundry/unit/ClientChainGateway.t.sol (27)

26-27: Renamed imports
These imports accurately reflect the rebranding from Exocore to Imuachain. No issues found.

---

34-34: New interface import
The import for IImuaCapsule aligns well with the new naming convention.

---

60-60: Renaming gateway variable
Switching to imuachainGateway is consistent with the rebrand.

---

66-66: Capsule interface renamed
The introduction of IImuaCapsule in place of the old capsule interface appears correct.

---

83-83: Defining owner
Assigning a dedicated Player structure for ownership is a clear approach.

---

89-89: Owner funding
Providing 100 ether for the test owner is standard practice and should not pose issues.

---

96-96: Updating setDestLzEndpoint
Reflecting the rename for imuachainGateway and imuachainLzEndpoint. No concerns here.

---

100-100: Defining peer gateway
setPeer(imuachainChainId, address(imuachainGateway).toBytes32()) ensures the gateway is recognized in cross-chain calls.

---

106-106: Beacon oracle instantiation
Constructing the oracle with EigenLayerBeaconOracle. Confirm the NetworkConstants.getBeaconGenesisTimestamp() usage aligns with your deployment.

---

111-111: Deploying ImuaCapsule
Allocating capsuleImplementation = new ImuaCapsule(address(0)) appears to be a placeholder. Verify if a more specific address is needed.

---

120-120: Creating restakeToken
Minting 1e16 tokens to the owner is fine for test usage. Ensure total supply meets test objectives.

---

122-122: Mock endpoint initialization
Constructing NonShortCircuitEndpointV2Mock(clientChainId, owner.addr) is standard for simulations.

---

126-126: Using imuachainChainId in config
Check that this chain ID is consistently used across scripts for chain gating.

---

129-129: Renamed capsule beacon
imuaCapsuleBeacon replaces references to the old capsule name. No issues found.

---

145-146: generateUID function
Accounting for the direction (fromClientChainToImuachain) is logical and maintains clarity in UID generation.

---

148-148: UID parameters for forward direction
Inserting clientChainId before imuachainChainId is correct as per the argument order. Double-check usage.

---

152-152: UID parameters for reverse direction
Swapping chain IDs for the opposite flow is appropriate.

---

218-218: claimPrincipalFromImuachain
Renamed for clarity. The modified function name aligns with the new chain brand.

---

228-229: test_ImuachainChainIdInitialized
Verifies IMUACHAIN_CHAIN_ID() matches imuachainChainId. Good coverage for chain ID configuration.

---

253-253: test_ImuaCapsuleBeaconInitialized
Ensures the named beacon is properly set to the client gateway.

---

255-255: Asserting correct beacon address
Checks that clientGateway.IMUA_CAPSULE_BEACON() matches the deployed capsuleBeacon.

---

258-258: Asserting new owner
assertEq(clientGateway.owner(), owner.addr) is aligned with the rename from the exocore approach.

---

346-346: Renamed withdrawal contract
WithdrawalPrincipalFromImuachain is consistent with the broader shift away from Exocore.

---

62-62:

✅ Verification successful

Renaming LZ Endpoint reference
Adopting imuachainLzEndpoint is part of the rename. Confirm usage in downstream code.

---

🏁 Script executed:

#!/bin/bash
rg imuachainLzEndpoint

Length of output: 7028

---

Verified: LZ Endpoint Rename Usage Confirmed
The variable imuachainLzEndpoint is now consistently used across the codebase—including deployment scripts and all relevant tests—as expected with the rename. No discrepancies were found in downstream code, so no further changes are necessary.

---

72-73:

❓ Verification inconclusive

Hard-coded chain ID and operator
Setting imuachainChainId = 2 and operatorAddress in code is fine for tests, but verify these are correct for your environment.

---

🏁 Script executed:

#!/bin/bash
rg 'imuachainChainId ='
rg 'operatorAddress ='

Length of output: 1293

---

Verify your hard-coded test parameters

The file test/foundry/unit/ClientChainGateway.t.sol hard-codes imuachainChainId as 2 and sets operatorAddress to "im13hasr43vvq8v44xpzh0l6yuym4kca983u4aj5n". We observed that several tests use similar values (e.g., in Governance.t.sol and ImuachainDeployer.t.sol), while others (like in ImuachainGateway.t.sol and some deployment scripts) use different values. Please double-check that these specific values (chain ID 2 and the given operator address) are intentional and correctly represent your intended test environment configuration. If they are based on environmental assumptions, documenting or centralizing these parameters may help avoid potential discrepancies in the future.

---

53-53:

✅ Verification successful

Renaming variable to owner
This change clarifies ownership. Ensure any old references to the previous variable name are fully removed.

---

🏁 Script executed:

#!/bin/bash
rg exocoreValidatorSet

Length of output: 24

---

Renaming variable to owner confirmed
The variable in test/foundry/unit/ClientChainGateway.t.sol has been updated to owner to enhance clarity regarding ownership. A recursive grep for exocoreValidatorSet returned no results, indicating that references to the old variable name have likely been removed. Please verify that no indirect references (e.g., in comments or documentation) remain.

---

87-88:

✅ Verification successful

Setting test addresses
Using 0xc and 0xd as placeholders for imuachainGateway and imuachainLzEndpoint is reasonable, but confirm they are not mistaken for production addresses.

---

🏁 Script executed:

#!/bin/bash
rg 'address(0xc)' -A 3
rg 'address(0xd)' -A 3

Length of output: 49

---

Below is a new shell script to re-verify that the test file indeed uses these placeholder addresses using proper regex escapes:

Once these commands produce the expected output, please verify that 0xc and 0xd are indeed used solely as test placeholders and not mistakenly used as production addresses.

Review Verification: Placeholder Addresses in Test File

• Confirm that the test file (test/foundry/unit/ClientChainGateway.t.sol) shows the intended placeholder addresses in use, and that they are only present in the testing context.
• Ensure that the same addresses aren’t used in production-related code.

---

🏁 Script executed:

#!/bin/bash
echo "Verifying placeholder addresses in test/foundry/unit/ClientChainGateway.t.sol:"
rg "address\(0x[cC]\)" -n test/foundry/unit/ClientChainGateway.t.sol || echo "No occurrence of address(0xc) found."
rg "address\(0x[dD]\)" -n test/foundry/unit/ClientChainGateway.t.sol || echo "No occurrence of address(0xd) found."

Length of output: 448

---

Review Verification – Placeholder Addresses Confirmed

The placeholder addresses 0xc and 0xd are correctly used in the test file (test/foundry/unit/ClientChainGateway.t.sol) as test addresses and do not appear to be used in any production context. No changes are needed.

script/integration/1_DeployBootstrap.s.sol (8)

24-24: Added ImuaCapsule import
Switching from ExoCapsule to ImuaCapsule aligns with the rename throughout the codebase.

---

26-26: Importing IImuaCapsule
Matches the new interface name for the Imua capsule functionality.

---

38-38: Updated docstring
Reflects establishing the “initial state of Imuachain.” Strictly a doc change, no issues.

---

68-68: IImuaCapsule variable
Consistent with the code’s shift to Imua-based functionalities.

---

190-190: Instantiating ImuaCapsule
Providing the network config address to the constructor. Verify correctness of the configuration contract.

---

204-204: Setting imuachainChainId in ImmutableConfig
Ensures the bootstrap script references the correct chain ID.

---

207-207: Renaming imuaCapsuleBeacon
Part of the refactoring from exo references. The new name is consistent.

---

49-49:

❓ Verification inconclusive

imuachainChainId set to 1
This value may represent mainnet. Confirm it aligns with intended deployment.

---

🏁 Script executed:

#!/bin/bash
rg 'imuachainChainId = 1'

Length of output: 332

---

Confirm Correct Chain ID for Deployment

The variable imuachainChainId is set to 1 across the integration and test files (including script/integration/1_DeployBootstrap.s.sol, test/foundry/BootstrapDepositNST.t.sol, test/foundry/unit/Bootstrap.t.sol, and test/foundry/unit/ImuachainGateway.t.sol). Since a chain ID of 1 typically represents Ethereum mainnet, please verify that this hardcoded value is intentional for the intended deployment and testing scenarios. If not, consider updating or parameterizing the value accordingly.

test/foundry/unit/ImuaCapsule.t.sol (13)

9-10: Switch to ImuaCapsule
Replaced old Exo imports with new Imua variants, keeping consistency across the code.

---

14-14: Updated storage reference
ImuaCapsuleStorage is a direct rename from the Exo prefix. No issues found.

---

34-34: Renamed capsule variable
The local ImuaCapsule instance is correctly rebranded.

---

77-77: Phantom ImuaCapsule
Instantiating a dummy capsule at address(0). Suitable for testing.

---

80-81: Etching code for mocking
vm.etch overwrites the code at capsuleAddress with the phantom capsule’s code, then casts it to ImuaCapsule. Valid approach for advanced test scenarios.

---

159-161: Validator retrieval
Ensures the validator’s status is updated to REGISTERED after deposit proof verification. Logic looks correct.

---

183-183: Revert on double deposit
ImuaCapsule.DoubleDepositedValidator revert is suitably named to reflect repeated deposit attempts.

---

230-231: Invalid validator container revert
Renamed from the old ExoCapsule variant. The revert reason is clearly expressed for incorrect validator data.

---

283-283: Creating anotherCapsule
Used for mismatch testing. The constructor with address(0) is fine as a placeholder.

---

293-293: Revert on mismatched withdrawal credentials
ImuaCapsule.WithdrawalCredentialsNotMatch captures the error scenario accurately.

---

340-340: Renamed WithdrawalAlreadyProven
Adopts the Imua naming convention for the error context.

---

528-528: Verifying withdrawal proof
The function call now references ImuaCapsule logic. This ensures partial or full withdrawals are tested.

---

538-538: Repeated DBL-withdrawal revert
ImuaCapsule.WithdrawalAlreadyProven is reused for subsequent tests, confirming coverage.

test/foundry/ImuachainDeployer.t.sol (17)

18-19: Use of new imports aligned with rebranding
These import statements correctly reference the new ImuaCapsule and ImuachainGateway contracts, aligning with the renaming from Exocore to Imua.

---

49-49: Renamed contract aligns with the new naming convention
Renaming ExocoreDeployer to ImuachainDeployer is consistent with the overall rebranding. Verify that all references (including test descriptions and doc strings) are updated accordingly.

---

56-56: Introducing the owner as a Player
Storing an owner of type Player is fine for testing. Just ensure there is no conflict with other “owner” definitions if used in contracts or test frameworks.

---

129-131: Initializing outbound/inbound nonces
Setting inbound/outbound nonces for imuachainChainId to 1 ensures message ordering starts from a known index. The logic is straightforward and aligns with bridging patterns.

---

138-138: Assigning test owner
Assigning the test owner with a private key 0xa is a standard approach in Foundry-based tests. No issues found.

---

163-163: Funding the owner for testing
Providing 1e22 to owner.addr helps ensure sufficient test funds. This is standard practice in your test environment.

---

190-191: Comment and test setup
Line 190 is a clarifying comment; line 191 starts the prank with the designated owner. Both changes are straightforward with no issues.

---

198-199: Event emission and gateway calls
These lines add test coverage via expectEmit on imuachainLzEndpoint and imuachainGateway, then invoke addWhitelistToken. This is a clean approach to verifying emitted events. No functional issues detected.

Also applies to: 201-201, 204-204, 209-209, 216-216

---

236-236: Use of Origin constructor
Passing (imuachainChainId, address(imuachainGateway).toBytes32(), inboundNonces[clientChainId] - 1) is valid for simulating inbound messages after incrementing the local inbound nonce.

Also applies to: 248-248

---

274-275: Symmetry in nonce validation
Verifying outboundNonces[imuachainChainId] == inboundNonces[clientChainId] and vice versa helps confirm that all outbound messages on chain A have been executed on chain B. This properly checks bridging parity.

---

329-331: Instantiating mocks and ERC20PresetFixedSupply
Deploying restakeToken with supply 1e34 is suitable for stress testing. Both clientChainLzEndpoint and imuachainLzEndpoint appear correct.

Would you like to confirm that 1e34 meets your integration or mainnet environment supply constraints by searching external references or verifying in the codebase?

---

337-337: Constructing ImuaCapsule with null address
Passing address(0) to the ImuaCapsule constructor can be valid if the logic is intended to initialize references later. Ensure no subsequent calls rely on a non-zero address.

---

358-358: Immutable config for imuachainChainId & imuaCapsuleBeacon
Storing these references in BootstrapStorage.ImmutableConfig is consistent with your pattern. No issues detected, but do ensure you handle re-deployment if chain IDs differ across environments.

Also applies to: 361-361

---

375-375: Encoding the initializer call
Using abi.encodeWithSelector(clientGatewayLogic.initialize.selector, payable(owner.addr)) is correct for TransparentUpgradeableProxy. The code is clean.

---

388-390: Deploying and initializing ImuachainGateway
Lines 388–390 and 394–396 collectively deploy the new gateway logic and proxy. This properly mirrors the pattern used for clientGateway. Looks consistent.

Also applies to: 394-394, 396-396

---

404-404: Configuring LZ endpoints and startPrank
Points lines 404 & 407 cross-wire the endpoints to fully simulate the bridging environment. The vm.startPrank(owner.addr) at line 410 is also standard in Foundry.

Also applies to: 407-407, 410-410

---

413-415: Peer registration for Imuachain
Line 413 is an explanatory comment. Lines 414–415 set the peer references and call registerOrUpdateClientChain for imuachainGateway. This is correct for bridging setups.

src/core/UTXOGateway.sol (7)

5-5: Introducing ImuachainBytes
Replacing the previous bytes utility with ImuachainBytes aligns with the Imua rebranding.

---

19-19: Updated documentation references to Imua
These docstring lines now correctly mention “Imuachain” or “Imua”. Ensure that all references to the older brand are fully replaced throughout the codebase to maintain consistency.

Also applies to: 30-30, 51-51, 92-92

---

254-254: Clarifying the operator's Imuachain address
Updating docstrings to reflect the operator’s “Imuachain” address improves clarity for external integrators. No functional issues seen.

Also applies to: 281-281

---

299-299: Using msg.sender.toImuachainBytes()
Wrapping the sender address with toImuachainBytes() ensures correct cross-chain representations. Confirm that these conversions match the chain’s expected byte format.

Also applies to: 320-320, 345-345

---

431-431: Getter functions referencing Imuachain vs. client addresses
These lines rename or clarify function signatures to invert the address lookup. The approach for bridging addresses is coherent, returning the correct mappings in inboundRegistry and outboundRegistry.

Also applies to: 436-436, 440-440, 445-445

---

674-674: Signature encoding includes _msg.imuachainAddress
Extending the stake message to incorporate imuachainAddress ensures traceability. Confirm all upstream signers are aware of the new field in the signature.

---

839-839: Registering the Imuachain address, delegating on stake, and emissions

• Line 839 checks that no prior address registration exists.
• Line 841 ensures _msg.imuachainAddress is non-zero.
• Line 857 attempts a _delegate, falling back to an event emission on failure (lines 860–862).
• Line 865 emits StakeMsgExecuted.

This flow is logically correct, preventing double registration, handling reverts or failures gracefully, and properly finalizing stake messages.

Also applies to: 841-841, 857-857, 860-862, 865-865

test/foundry/DepositWithdrawPrincipal.t.sol (33)

3-4: Imports updated to Imua references.
These imports appear consistent with the rebranding to ImuaCapsule and ImuachainGateway. No issues found.

---

7-7: New interface import.
Importing the IImuaCapsule interface aligns with the codebase rename and is consistent with the usage below. Looks good.

---

11-11: Test harness inheritance changed.
Referencing "./ImuachainDeployer.t.sol" is coherent with the rebranding. No apparent concerns.

---

18-18: Contract rebranded to ImuachainDeployer.
Switching from the old deployer to ImuachainDeployer clarifies the new chain identity. No issues found.

---

41-41: vm.startPrank(owner.addr) usage.
This ensures the subsequent calls are made from the designated owner. Code usage is standard in Foundry tests.

---

125-127: LST Transfer event coverage.
These lines validate the LSTTransfer event emission. The change to label it as an Imuachain event is consistent with the rename.

---

139-140: Origin param updated
Using address(imuachainGateway) and referencing clientChainId clarifies the cross-chain origin within the new chain context.

---

177-179: claimPrincipalFromImuachain invocation.
Switching from the old claim method to Imuachain naming is consistent. The call structure appears correct, passing the correct arguments and fee.

---

186-187: Setting up withdrawal response fee and ID.
Renaming to withdrawResponseNativeFee and generating a new UID for Imuachain usage are logically consistent.

---

189-189: Event expectation for imuachainGateway.
This test line ensures the correct contract emits the event. No issues.

---

200-200: Emitting MessageExecuted for deposit.
The increment inboundNonces[imuachainChainId]++ is correct for message counters.

---

203-203: Passing correct address as Bytes32.
imuachainGateway.toBytes32() is consistent with the cross-chain referencing strategy. Looks good.

---

208-209: Expecting MessageSent event.
Ensures that the deposit request triggers the MessageSent event on the Imuachain gateway. Correct usage.

---

217-218: Setting up Origin with updated gateway.
Continues the rename from Exocore to Imuachain. The usage is aligned with new chain IDs.

---

224-226: Fund imuachainGateway for gas fees.
The inline comment clarifies the reason for transferring 1e22. This is helpful for debugging.

---

229-229: Principal unlocked event emission.
Provides test coverage that unlocked principal triggers the correct event. No issues.

---

258-260: Additional gateway funding for withdrawal fees.
Consistent approach. No concerns.

---

299-301: Attempting invalid deposit scenario.
This test ensures proper revert when the deposit would exceed TVL. Good negative test coverage.

---

303-304: Simulating message on Imuachain gateway.
Line 304 increments principalBalance; clarifies cross-chain deposit logic. Implementation looks consistent.

---

323-324: Potential case-sensitive typo in action string.
Action.REQUEST_WITHdraw_LST has a lowercase letter in "WITHdraw". Verify if this is intentional or consistent with enumeration.

---

327-331: LST withdrawal request events & call.
Tests the MessageSent event with the new Action, then calls claimPrincipalFromImuachain. The usage pattern is correct.

---

340-340: LayerZero response watchers comment.
Renamed comment clarifies the chain bridging approach. No issues found.

---

352-353: NST deposit message executed.
Ensures the event indicates the deposit logic for "native staked token." Good clarity.

---

371-372: Deposit set to 32 ether & new event expectation.
Explicitly using 32 ether for LST deposit is consistent with typical staking scenarios.

---

379-384: Capsule creation & staking flow.
The consecutive events (CapsuleCreated, StakedWithCapsule) ensure coverage. The actual call to stake{value: 32 ether} is correct.

---

392-392: Simulating block environment.
Calling _simulateBlockEnvironmentForNativeWithdraw() plus dealing 1 extra ether for testing edge cases is well structured.

Also applies to: 394-395

---

399-399: Reading principal balance.
No functional issue. This check ensures the correct starting balance prior to withdrawal.

---

403-403: Preparing request payload for withdraw.
Combines the deposit address and VIRTUAL_STAKED_ETH_ADDRESS. The approach is consistent with the cross-chain format.

Also applies to: 405-405

---

413-414: Claiming from Imuachain & stopping prank.
Ensures that the correct function call is tested with the expected parameters. Implementation matches naming.

Also applies to: 416-416

---

432-433: Emitting a MessageSent from Imuachain gateway.
Validates the bridging event after claiming. Looks correct.

---

502-502: Expecting final event on Imuachain gateway.
Consistent coverage for verifying that the last message stage is properly executed.

---

703-704: Unit deposit scenario test.
Verifies a small deposit. Good for boundary condition coverage.

---

765-766: Exceeding TVL UX check.
The revert check here ensures user attempts beyond the limit are blocked. Great coverage.

script/generate.mjs (14)

14-15: Renaming token meta info.
Switched to "Imuachain Holesky ETH" for clarity. The second line "Staked ETH" remains consistent with prior naming.

---

26-27: nativeChain rename.
Renamed to "Imuachain," reflecting the new chain name. No functionality concerns.

---

34-35: Updating asset name and symbol.
Using "Native IMUA token" and "IMUA" is consistent with the rebrand. No issues.

---

39-40: Chain index meta info.
Renaming references to "imua_chain_index" clarifies the chain context.

---

44-44: Bech32 prefix changed to im.
Ensures bech32 addresses start with "im". This is consistent with your new naming scheme.

---

63-63: Bech32 validation logic.
Ensures the prefix is "im". This is essential for Imuachain bech32 compliance.

---

249-249: Unused placeholder for imua_chain_index.
Comment indicates it’s unused but stored. Confirm whether it’s needed for future expansions or can be removed.

---

703-703: Slash proportion calculations.
Renamed references continue to reflect the rebranding. No immediate logic concerns.

---

757-757: Adding native chain to client_chains.
Ensures Imuachain is appended if it doesn't exist. Maintains consistent chain data structure.

---

759-759: Adding nativeAsset to assets.tokens.
Similar logic ensures the new chain’s native asset is recognized in the genesis file.

---

762-763: Hex suffix for chain ID.
Appends '_0x' plus the chain ID in hex, consistent with existing practice for chain identification.

---

766-766: Ensuring dogfood parameters remain consistent.
Renaming references does not affect logic, but verifying consistency in consumption is important.

---

769-769: Double-check final jsonBig.stringify usage.
Output consistency is important for ensuring correct genesis file structure after rebrand changes.

---

1209-1210: Capsule references to imuaCapsuleBeacon.
Correctly updated references to imuaCapsuleBeacon in config. Looks aligned with the rest of the code.

test/foundry/unit/Bootstrap.t.sol (47)

39-39: Importing ImuaCapsule.sol.
Replaces the old ExoCapsule import. Aligned with the renamed code references.

---

64-64: Setting imuachainChainId = 1.
Confirms the chain ID is assigned to 1 for local testing. This is a potential placeholder—verify if 1 is the final.

---

70-70: Renamed to undeployedImuachainGateway.
Matches rebranding. No logic changes aside from the name.

---

73-73: Renamed capsuleImplementation.
Uses ImuaCapsule type. No issues.

---

125-125: Using address(clientChainLzEndpoint) in the config.
Links the correct argument for the new chain endpoint. Good consistency.

---

134-134: Initialize call with payable(owner)
Ensures the correct ownership is passed in for setUp.

---

137-137: Spawning with spawnTime and offset.
No issues. Validation confirms the new chain’s bootstrap timing.

---

176-178: Setting peer for Imuachain.
Utilizes setPeer(imuachainChainId, …) to store the remote gateway. This is the new approach consistent with rebranding.

---

461-464: Imuachain address checks.
The lines "im13hasr..." confirm use of the new prefix "im". Matches the bech32 prefix approach.

---

493-504: Registered validator switching from exocore to imuachain naming.
All rename references look consistent. Checking logic reveals no functional changes aside from the naming.

---

507-522: Handling collisions in im addresses.
The test ensures a second validator can’t reuse the same im address. Good coverage.

---

525-541: Checking consensus key collisions.
Confirms that a second validator can’t reuse an existing key. Proper error revert.

---

547-560: Handling name collisions.
Ensures a new validator can’t reuse an existing name in the new im environment.

---

566-572: Empty name revert.
Test for a validated im address but an empty name. No logic concerns.

---

577-583: Zero consensus key revert.
Prevents a no-key scenario from being registered. This is a good security check.

---

590-593: depositThenDelegateTo referencing the new im prefix.
All logic remains the same, with the rebranding applied.

---

607-611: Same pattern for registerValidator.
Renamed im address usage is consistent. No adverse effects.

---

613-613: Public key retrieval.
Still sets consensusPublicKey. No logic changed, aside from naming.

---

625-633: replaceKey rename.
Ensures old references to exo keys replaced with imua references. No logic issue.

---

640-643: Replacing key duplication check.
Matches the newly minted chain references for collisions.

---

669-669: Using updateRate with new chain config.
No differences beyond naming. Implementation remains consistent.

---

683-689: Verifying rate changes for rebranding.
The rebrand doesn't affect logic. The error messages remain coherent.

---

699-703: vm.expectRevert(Errors.BootstrapRateExceedsMaxRate.selector)
Now references the rebranded error. Logic demanded no changes, so it’s consistent.

---

708-717: Rate limit checks.
No functional changes. The rename is correct.

---

757-758: Ensuring isValidImAddress("im...").
New prefix test. Good coverage for the rebranded address format.

---

762-767: Prefix and length validations
Ensures invalid prefix or extra length reverts. Thorough test coverage.

---

777-820: Delegate/Undelegate references with new im.
All references systematically replaced. The approach remains functionally identical.

---

948-949: test11_ClaimPrincipalFromImuachain
Renamed from Exocore methods. Checking the deposit vs. principal shift logic remains correct.

Also applies to: 950-951, 952-953

---

975-979: Token whitelisting check.
Reverts if the token isn’t recognized in the new chain context. Good coverage.

---

982-986: Zero amount revert.
Consistent with the new naming scheme.

---

989-993: BootstrapInsufficientDepositedBalance
Name aligns with the rename. The test logic remains the same.

---

995-1001: Excess deposit revert.
Now references Imuachain. Rebranding only.

---

1004-1009: Withdrawable vs. delegated balance check
Ensures consistent logic under the new method name.

---

1303-1313: Marking as bootstrapped after Imuachain's spawn time.
Renaming references from old chain to Imuachain. The logic for time-based checks remains unchanged.

---

1547-1551: Prohibiting Ether usage with deposit calls.
Ensures Errors.NonZeroValue reverts remain. Renaming does not affect functionality.

Also applies to: 1556-1560

---

1621-1631: createImuaCapsule
Renamed from old capsule creation method. Confirms a correct address.

---

1633-1642: Rejecting second createImuaCapsule.
Prevents an existing staker from re-creating a capsule. Good coverage.

---

1644-1651: Failing createImuaCapsule if disabled.
Consistent with disabling native restaking in Imuachain. No functional issues.

---

1680-1691: verifyAndDepositNativeStake test.
Fully rebranded references. The logic for deposit and withdraw matches the new chain environment.

---

1693-1706: Prohibiting Ether usage in verifyAndDepositNativeStake.
Stays consistent with prior constraints. The renaming is consistent.

---

1708-1719: No capsule scenario
Reverts if no capsule is created. Maintains the rebranded code lines.

---

1721-1731: verifyAndDepositNativeStake when disabled
Again ensures rebranding does not break the underlying logic.

---

1734-1752: withdrawNonBeaconChainETHFromCapsule
Renamed usage from the old Exo naming. The logic stands.

---

1754-1765: No capsule check for non-beacon chain withdrawal
Mirrors the rebrand. The logic is stable.

---

1767-1777: Disable check for withdrawNonBeaconChainETHFromCapsule
Again consistent with the rebranding.

---

1780-1792: processBeaconChainWithdrawal not yet supported
Renamed references for the chain. The function’s revert remains.

---

1794-1806: Disable check for processBeaconChainWithdrawal
Matches rebranding; logic unchanged.

src/libraries/ImuachainBytes.sol (1)

4-13: LGTM! Clean and well-documented implementation.

The library provides a clear and efficient implementation for converting Ethereum addresses to Imuachain's 32-byte format. The function is properly documented with NatSpec comments and uses appropriate type casting and encoding.

script/9_ExtendBootstrapTime.s.sol (1)

24-24:

❓ Verification inconclusive

Verify owner permissions for bootstrap time modification.

The change from exocoreValidatorSet.privateKey to owner.privateKey aligns with the rebranding. However, ensure that the owner account has the necessary permissions to modify the bootstrap time.

---

🏁 Script executed:

#!/bin/bash
# Check if owner has appropriate role/permissions
ast-grep --pattern $'contract Bootstrap {
  $$$
  function setSpawnTime($_) {
    $$$
  }
  $$$
}'

Length of output: 99

---

Action Required: Confirm Owner's Permission for Bootstrap Time Modification

The rebranding change to use owner.privateKey looks correct, but the automated search for the access control logic (specifically within the setSpawnTime function inside the Bootstrap contract) returned no results. This indicates that either the function’s signature or its internal permission checks aren’t detectable through the current AST search.

Next Steps:

• Please manually verify that the Bootstrap contract enforces the necessary permissions (e.g., through an onlyOwner modifier or equivalent logic) for modifying the bootstrap time.
• If access control logic is missing or unclear for the owner account, consider adding appropriate validation to ensure that only authorized accounts can set the spawn time.

hardhat.config.js (1)

20-24:

❓ Verification inconclusive

Verify environment variable availability.

The network and environment variable renaming aligns with the rebranding. Ensure that the new environment variable LOCAL_IMUACHAIN_FUNDED_ACCOUNT_PRIVATE_KEY is properly documented and available in the environment configuration.

---

🏁 Script executed:

#!/bin/bash
# Check if the new environment variable is documented
rg "LOCAL_IMUACHAIN_FUNDED_ACCOUNT_PRIVATE_KEY" .env.example

Length of output: 60

---

Verify Environment Variable Documentation

• The new network configuration uses the rebranded environment variable LOCAL_IMUACHAIN_FUNDED_ACCOUNT_PRIVATE_KEY.
• A search in .env.example did not return any results, so it’s unclear whether this variable is properly documented.
• Please perform a manual verification to ensure that LOCAL_IMUACHAIN_FUNDED_ACCOUNT_PRIVATE_KEY is included in the environment configuration documentation (e.g., in .env.example, README, or related documentation files).

script/16_UpgradeImuaCapsule.s.sol (1)

3-3:

❓ Verification inconclusive

Verify storage layout compatibility.

The renaming from ExoCapsule to ImuaCapsule requires careful verification of storage layout compatibility to ensure a safe upgrade.

Also applies to: 8-8, 27-27

---

🏁 Script executed:

#!/bin/bash
# Search for storage layout declarations in both old and new contracts
ast-grep --pattern $'contract $_ {
  $$$
  uint256 $_; // Look for storage variables
  $$$
}'

Length of output: 94

---

Manual Verification Needed: Confirm Storage Layout Compatibility

The ast-grep command did not return any output, so we couldn’t automatically verify the state variables. Please manually confirm that the storage layout (i.e., the order and types of state variable declarations) in ImuaCapsule aligns with what existed in ExoCapsule. This verification is crucial to ensure a safe upgrade—especially considering the changes referenced on lines 8 and 27.

src/interfaces/precompiles/IBech32.sol (2)

15-27: LGTM! Well-documented interface with clear method signatures.

The interface is properly documented with NatSpec comments and the method signatures are clear and concise.

---

4-7:

❓ Verification inconclusive

LGTM! Well-defined precompile address constant.

The precompile address is correctly defined as an immutable constant and the interface instance is properly created.

Please verify that 0x400 is the correct precompile address for the Bech32 converter on the Imua chain:

---

🏁 Script executed:

#!/bin/bash
# Check if the precompile address is registered
rg -A 5 "0x0000000000000000000000000000000000000400" --type go

Length of output: 211

---

Rewritten Review Comment:

LGTM! Well-defined precompile address constant.
The precompile address is correctly defined as an immutable constant, and the interface instance is properly created. However, note that the initial attempt to verify the precompile address using a query filtered by Go files did not search the Solidity code. Please ensure that 0x0000000000000000000000000000000000000400 is indeed the correct precompile address for the Bech32 converter on the Imua chain by re-running the above command (which searches Solidity files) or performing a manual verification if needed.

---

🏁 Script executed:

[run_scripts]
#!/bin/bash
# Re-run the search for the Bech32 precompile address in Solidity files.
# This command searches for the precompile address in files with the Solidity (.sol) extension.
rg -n "0x0000000000000000000000000000000000000400" --type sol

Length of output: 211

---

LGTM! Well-defined precompile address constant.
The interface correctly declares the precompile address as an immutable constant and instantiates the contract instance using it. However, note that our previous automated searches did not inspect the Solidity files properly. Please verify manually (or via the script above) in the file src/interfaces/precompiles/IBech32.sol that the address 0x0000000000000000000000000000000000000400 is indeed intended as the precompile address for the Bech32 converter on the Imua chain.

---

🏁 Script executed:

[run_scripts]
#!/bin/bash
# Search for the precompile address in the IBech32 Solidity interface file.
grep -H "0x0000000000000000000000000000000000000400" src/interfaces/precompiles/IBech32.sol

Length of output: 443

---

LGTM! The precompile address constant is correctly defined.
The constant BECH32_PRECOMPILE_ADDRESS is present in src/interfaces/precompiles/IBech32.sol (both in its declaration and documentation comment), and the interface instance is properly created. Please manually verify that the address 0x0000000000000000000000000000000000000400 indeed corresponds to the correct Bech32 converter precompile for the Imua chain.

script/19_DeployFaucet.s.sol (2)

24-25: LGTM! Fork selection and initialization logic updated correctly.

The fork selection and initialization logic has been properly updated to use Imua chain references.

Also applies to: 36-37, 43-43

---

13-13:

❓ Verification inconclusive

LGTM! Consistent rebranding of faucet variables.

The boolean flag has been correctly renamed from exoEthFaucet to imEthFaucet and the environment variable has been updated accordingly.

Please verify that the environment variable has been updated in the CI configuration:

Also applies to: 30-30

---

🏁 Script executed:

#!/bin/bash
# Check if IM_ETH_FAUCET is defined in CI
rg "IM_ETH_FAUCET" .github/

Length of output: 27

---

Attention: Verify CI Environment Variable Configuration

LGTM on the consistent rebranding of faucet variables (i.e. renaming from exoEthFaucet to imEthFaucet). However, the search for the IM_ETH_FAUCET environment variable in the CI configuration (under .github/) returned no results. Please manually confirm that this environment variable update is correctly reflected in all relevant CI configuration files (including the update at line 30-30).

script/6_CreateImuaCapsule.s.sol (1)

5-5:

✅ Verification successful

LGTM! Consistent rebranding of gateway and capsule references.

The imports, variable names, and function calls have been correctly updated to use Imua chain references.

Since the PR objectives mention potential storage layout issues, let's verify the storage compatibility:

Also applies to: 32-32, 40-41, 48-48

---

🏁 Script executed:

#!/bin/bash
# Check if the storage layout files exist and are being compared
rg "ImuaCapsule\.(deployed|compiled)\.json" script/
rg "ImuachainGateway\.(base|compiled)\.json" script/

Length of output: 356

---

Approval Notice: Rebranding and Storage Layout Verified

The updated import statement along with variable names and function calls has been correctly rebranded to Imua chain references. The storage layout verification in script/compareLayouts.js confirms that both the capsule (ImuaCapsule.deployed.json and ImuaCapsule.compiled.json) and the gateway (ImuachainGateway.base.json and ImuachainGateway.compiled.json) files are present and correctly compared.

• Rebranding changes are consistent.
• Storage layout compatibility is verified (see script/compareLayouts.js for lines 32, 40, and 48).

LGTM!

script/compareLayouts.js (1)

10-11:

❓ Verification inconclusive

LGTM! File mappings updated for storage layout comparison.

The file mappings have been correctly updated to compare storage layouts for ImuaCapsule and ImuachainGateway.

Let's verify that the storage layout files are generated during the build:

---

🏁 Script executed:

#!/bin/bash
# Check the build process for storage layout file generation
rg "ImuaCapsule\.(deployed|compiled)\.json" package.json forge.toml
rg "ImuachainGateway\.(base|compiled)\.json" package.json forge.toml

Length of output: 242

---

Storage layout mappings updated – please verify file generation manually

The file mappings in script/compareLayouts.js for ImuaCapsule and ImuachainGateway have been correctly updated. However, our automated search for storage layout files (using the build process check) returned inconclusive results (an error regarding forge.toml was observed). Please manually verify that the build process generates the expected storage layout files (for both the deployed/compiled and base/compiled variants) and update the build configuration if needed.

src/core/BootstrapLzReceiver.sol (2)

12-13: Documentation update looks good.

The author and notice updates are consistent with the rebranding effort.

---

28-28:

✅ Verification successful

Verify IMUACHAIN_CHAIN_ID constant definition.

The chain ID validation is critical for message security. Please ensure that IMUACHAIN_CHAIN_ID is properly defined and consistent across the codebase.

---

🏁 Script executed:

#!/bin/bash
# Search for IMUACHAIN_CHAIN_ID definitions and usages
echo "Searching for IMUACHAIN_CHAIN_ID definitions:"
rg -A 2 "IMUACHAIN_CHAIN_ID\s*=.*" 

echo -e "\nSearching for IMUACHAIN_CHAIN_ID usages:"
rg "IMUACHAIN_CHAIN_ID"

Length of output: 1371

---

Chain ID definition and usage verified as consistent across the codebase

• The IMUACHAIN_CHAIN_ID constant is defined in src/storage/BootstrapStorage.sol and correctly initialized via config.imuachainChainId.
• Its usage in src/core/BootstrapLzReceiver.sol (and other modules/tests) consistently checks against the intended chain ID, ensuring message security.
• Documentation updates related to the rebranding (changing from "Exocore" to "Imuachain") are in place.

script/11_SetPeers.s.sol (1)

35-56: Verify gateway peer setup sequence.

The peer setup sequence is critical for cross-chain communication. The changes look correct, but please ensure:

1. The order of operations (setPeer → markBootstrap) is maintained
2. The fee calculation uses the correct chain ID

src/utils/CustomProxyAdmin.sol (1)

11-11: Documentation update looks good.

The author update is consistent with the rebranding effort, and no functional changes were made to this contract.

script/15_DeploySafeMulstisigWallet.s.sol (1)

18-19:

✅ Verification successful

Verify RPC URL and genesis configuration.

Ensure that imuachainRPCURL and imuachainGenesis are properly configured in the environment.

---

🏁 Script executed:

#!/bin/bash
# Search for RPC URL and genesis configurations
rg "imuachainRPCURL|imuachainGenesis" --type-add 'env:*.env*' -t env

Length of output: 70

---

Please run the above script to gather additional evidence on whether these critical configuration variables exist anywhere in the repository.

Once confirmed, update the review comment accordingly if the configuration isn’t found or if manual verification is required.

---

Critical: Verify RPC URL and Genesis Configuration

• Action: Ensure that imuachainRPCURL and imuachainGenesis are defined and correctly configured.
• Location: Lines 18–19 in script/15_DeploySafeMulstisigWallet.s.sol
• Next Steps:
  • Run the global search script above to verify if these variables are declared anywhere in the repository.
  • Manually confirm that the intended configuration is loaded into the environment.

---

🏁 Script executed:

[run_scripts]
#!/bin/bash
# Perform a global search for definitions of imuachainRPCURL and imuachainGenesis
echo "Searching globally for imuachainRPCURL:"
rg -i "imuachainRPCURL" .
echo "-------------------------------------"
echo "Searching globally for imuachainGenesis:"
rg -i "imuachainGenesis" .

Length of output: 3502

---

Configuration Verification Complete: RPC URL & Genesis Settings

We've confirmed that the imuachainRPCURL and imuachainGenesis variables are consistently defined and used across the repository. In particular, the variable imuachainRPCURL is set in BaseScript.sol via the environment variable IMUACHAIN_TESTNET_RPC, and imuachainGenesis is properly initialized using IMUACHAIN_GENESIS_PRIVATE_KEY. This consistent setup is used in multiple scripts (including script/15_DeploySafeMulstisigWallet.s.sol), ensuring proper fork selection and genesis configuration.

• Action Item: Verify that the actual environment where the scripts are executed has the correct values for IMUACHAIN_TESTNET_RPC and IMUACHAIN_GENESIS_PRIVATE_KEY.
• Snippet Under Review:

          imuachain = vm.createSelectFork(imuachainRPCURL);
          _topUpPlayer(imuachain, address(0), imuachainGenesis, deployer.addr, 2 ether);

The configuration appears sound based on our repository search. Please double-check the runtime environment to ensure the environment variables are set as expected.

src/interfaces/ILSTRestakingController.sol (1)

27-27:

✅ Verification successful

Verify consistent renaming of claimPrincipalFromExocore across the codebase.

The function has been renamed from claimPrincipalFromExocore to claimPrincipalFromImuachain. Let's verify that all references to this function have been updated consistently.

---

🏁 Script executed:

#!/bin/bash
# Search for any remaining references to the old function name
rg "claimPrincipalFromExocore"

# Search for references to the new function name to ensure proper usage
rg "claimPrincipalFromImuachain"

Length of output: 3328

---

Consistent Function Renaming Verified

All references to the old function name have been successfully updated to claimPrincipalFromImuachain across the codebase. No remaining instances of claimPrincipalFromExocore were found, and the updated function is consistently used in contracts, documentation, and tests.

script/10_DeployImuachainGatewayOnly.s.sol (2)

30-42: LGTM! Well-structured proxy deployment pattern.

The deployment follows security best practices:

• Uses OpenZeppelin's TransparentUpgradeableProxy
• Properly initializes the implementation contract
• Correctly sets up the ProxyAdmin

---

20-21:

✅ Verification successful

Verify LayerZero endpoint configuration.

The script loads the LayerZero endpoint address from a JSON file. Ensure that the endpoint configuration is properly set up in the prerequisite contracts file.

---

🏁 Script executed:

#!/bin/bash
# Check if the prerequisite contracts file exists and contains the endpoint
if [ -f "script/deployments/prerequisiteContracts.json" ]; then
    jq -r '.imuachain.lzEndpoint' script/deployments/prerequisiteContracts.json
else
    echo "Prerequisite contracts file not found"
fi

Length of output: 177

---

LayerZero endpoint configuration verified and proxy deployment pattern approved.

The JSON file at script/deployments/prerequisiteContracts.json correctly provides a non-zero address (0x6EDCE65403992e310A62460808c4b910D972f10f) for the LayerZero endpoint, ensuring proper configuration. The deployment script’s use of the TransparentUpgradeableProxy pattern and initialization approach appears solid, so no changes are required at this stage.

src/interfaces/IBaseRestakingController.sol (1)

38-38:

✅ Verification successful

Verify consistent renaming of claimRewardFromExocore across the codebase.

The function has been renamed from claimRewardFromExocore to claimRewardFromImuachain. Let's verify that all references to this function have been updated consistently.

---

🏁 Script executed:

#!/bin/bash
# Search for any remaining references to the old function name
rg "claimRewardFromExocore"

# Search for references to the new function name to ensure proper usage
rg "claimRewardFromImuachain"

Length of output: 987

---

Renaming verified: All references updated

• No occurrences of the old function name claimRewardFromExocore were found.
• All instances now correctly use claimRewardFromImuachain across core contracts, interfaces, tests, and documentation.

script/integration/2_VerifyDepositNST.s.sol (1)

66-66:

❓ Verification inconclusive

Verify the validity of the new Imua address format.

The address has been updated from an Exocore format (exo1...) to an Imua format (im1...). Let's verify that this follows the correct bech32 address format for the Imua network.

---

🌐 Web query:

What is the correct bech32 address format for Imua network addresses?

💡 Result:

The search results provided do not explicitly mention an "Imua network" or its specific Bech32 address format. However, based on patterns observed in similar networks like IOTA and Shimmer, we can infer potential conventions:

1. General Bech32 Structure:
   Bech32 addresses follow the format:
   [human-readable part (HRP)]1[data + checksum]
   The HRP identifies the network (e.g., iota for IOTA Mainnet, smr for Shimmer Mainnet) [2][5][8].

2. Network-Specific HRPs:

   • IOTA: iota (Mainnet), atoi (Testnet)
   • Shimmer: smr (Mainnet), rms (Testnet) [5].
     If Imua follows this pattern, its HRP would likely be imua for Mainnet and a derivative like auim for Testnet.

3. Address Examples:

   • A hypothetical Imua Mainnet address might resemble:
     imua1q9f0mlq8yxpx2nck8a0slxnzr4ef2ek8f5gqxlzd0wasgp73utryj0w6qwt
   • Testnet: auim1... followed by encoded data [3][5].

For definitive confirmation, consult Imua's official documentation, as HRP conventions are network-specific and not universally standardized.

Citations:

• 1: https://en.bitcoin.it/wiki/Bech32
• 2: https://wiki.iota.org/tips/tips/TIP-0011/
• 3: https://hackmd.io/@iota-protocol/B13LrSkgv
• 4: https://learnmeabitcoin.com/technical/keys/address/
• 5: https://wiki.iota.org/tips/tips/TIP-0031/
• 6: https://www.archer-family-law.com/ethereum-why-bech32-address-always-starts-with-bc1q/
• 7: https://thebitcoinmanual.com/articles/btc-bech32-address/
• 8: https://d-central.tech/all-about-bech32-addresses/
• 9: https://github.com/mraksoll4/btcutil/blob/master/address.go
• 10: https://blockchain.news/wiki/know-your-bitcoin-address-differences-between-legacy-nested-segwit-and-native-segwit-formats

---

Verify the Imua Address Format

The updated test address now reads as:

"im1rtg0cgw94ep744epyvanc0wdd5kedwqlw008ex",

This string follows the bech32 structure (a human-readable part, separator, and data payload); however, based on patterns from similar networks (e.g., IOTA and Shimmer), Imua addresses would conventionally use an HRP like "imua" (for Mainnet) or perhaps "auim" (for Testnet). Currently, the HRP in this address is "im", which may not align with the expected convention.

• Action Item: Please verify against Imua’s official documentation to confirm whether the HRP "im" is correct or if it should be updated to "imua" (for Mainnet) or a designated Testnet counterpart.

src/core/LSTRestakingController.sol (2)

16-16: LGTM!

Author attribution has been updated to reflect the new organization.

---

45-45:

❓ Verification inconclusive

Verify storage layout compatibility.

While the function renaming from claimPrincipalFromExocore to claimPrincipalFromImuachain is consistent with the rebranding, we should verify that this change doesn't affect the storage layout as mentioned in the PR description.

---

🏁 Script executed:

#!/bin/bash
# Description: Check for storage layout changes using forge inspect
# Note: This helps identify if the function renaming affects storage slots

# Get storage layout for the current branch
forge inspect LSTRestakingController storage-layout > current_storage.txt

# Compare with the storage layout from the base branch
git checkout main
forge inspect LSTRestakingController storage-layout > base_storage.txt
git checkout -

diff base_storage.txt current_storage.txt

Length of output: 489

---

Action Required: Manual Verification of Storage Layout

The renaming of claimPrincipalFromExocore to claimPrincipalFromImuachain aligns with the rebranding. However, our automated storage layout check using forge inspect did not execute successfully because the forge command was not found. As a result, we couldn’t verify if the storage layout remains unchanged.

• Location: src/core/LSTRestakingController.sol (Line 45)
• Action: Please ensure that the storage layout remains consistent by running the storage inspection manually (or by installing/configuring the forge tool in your environment). This verification is crucial given the changes described in the PR.

script/1_Prerequisites.s.sol (1)

23-24: LGTM! Consistent renaming throughout the script.

The renaming from "exocore" to "imuachain" has been applied consistently across variables, function calls, and JSON output.

Also applies to: 35-38, 44-51, 64-68, 70-71, 74-74

src/interfaces/IImuaCapsule.sol (2)

6-10: LGTM! Interface documentation updated consistently.

The interface title, author, and notice have been updated to reflect the new naming convention.

---

12-15:

❓ Verification inconclusive

Verify interface implementations.

While the interface renaming is consistent, we should verify that all implementing contracts have been updated accordingly.

Also applies to: 59-60, 63-66

---

🏁 Script executed:

#!/bin/bash
# Description: Find all implementations of the renamed interface
# Note: This helps ensure no implementations were missed during the rename

# Search for old interface name references
echo "Checking for remaining references to IExoCapsule:"
rg "IExoCapsule"

# Search for implementations of the new interface
echo "Finding implementations of IImuaCapsule:"
ast-grep --pattern 'contract $_ is $$$, IImuaCapsule, $$$'

Length of output: 277

---

Interface renaming verified, but no implementations found.

• The search confirmed that all references to IExoCapsule have been removed.
• The AST search for implementations of IImuaCapsule didn’t return any results—please verify manually if contracts intended to implement this interface are not being missed due to formatting or additional inheritance patterns.
• Ensure that contract implementations (especially those noted at lines 59-60 and 63-66) are updated to correctly reference IImuaCapsule if they were expected to implement it.

src/interfaces/INativeRestakingController.sol (2)

8-12: LGTM! Interface documentation updated consistently.

The interface documentation has been updated to reflect the new branding.

---

24-27:

✅ Verification successful

Verify callers of renamed function.

The function has been renamed from createExoCapsule to createImuaCapsule. Let's verify that all callers have been updated.

---

🏁 Script executed:

#!/bin/bash
# Description: Find any remaining references to the old function name
# Note: This helps ensure no callers were missed during the rename

# Search for old function name references
echo "Checking for remaining references to createExoCapsule:"
rg "createExoCapsule"

# Search for calls to the new function name
echo "Finding calls to createImuaCapsule:"
ast-grep --pattern '$_.createImuaCapsule()'

Length of output: 267

---

Renamed Function Verified: No Outdated References Found

• The search using rg confirms that no references to createExoCapsule remain in the repository.
• The ast-grep search did not return any explicit calls to createImuaCapsule(), which is acceptable given that this is an interface method and may not be directly invoked in the codebase.

The rename appears complete. Please double-check external integrations or implementations to ensure they are also updated accordingly.

src/storage/GatewayStorage.sol (2)

67-67:

❓ Verification inconclusive

Verify the address length change.

The address length check has been updated from 42 to 41 characters to accommodate the new "im1" prefix. This change needs verification to ensure compatibility with all address-related functionality.

---

🏁 Script executed:

#!/bin/bash
# Search for any other address length checks that might need updating
ast-grep --pattern 'if ($x.length == 42) { $$$; }'

Length of output: 52

---

Manual Verification Required: Address Length Update

The change in GatewayStorage.sol at line 67—from checking for a length of 42 to 41 characters to accommodate the new "im1" prefix—appears to be the intended update. However, our automated search for other occurrences of a 42-length address check did not yield clear results. Given the low-confidence output from the shell script, I recommend manually verifying that all address-related functionality correctly handles the new 41-character addresses.

• File: src/storage/GatewayStorage.sol (line 67) – Ensure that this update aligns with address processing in related modules/tests.
• Action: Please double-check any logic or tests that rely on a fixed address length to confirm compatibility with the new "im1" prefix.

---

29-30:

✅ Verification successful

Verify the address prefix length impact.

The change from "exo1" to "im1" prefix affects the address validation logic. This change requires verification of the new address format's compatibility with existing systems.

---

🏁 Script executed:

#!/bin/bash
# Check if there are any hardcoded address validations or tests that might be affected
rg -A 2 "exo1|im1" 

Length of output: 14620

---

Address Prefix Update Verified

After reviewing the global usage of the address prefix, all instances—including validations and test cases—now consistently use the new "im1" prefix. The tests in both the storage contracts (e.g., in GatewayStorage.sol and UTXOGatewayStorage.sol) and the integration/unit tests confirm that the validation logic (e.g., checking for a 41-character address starting with "im1") has been fully updated and behaves as expected. Please ensure that any external systems interfacing with these addresses are also updated to accommodate the new "im1" format.

docs/native_deposit_workflow.wsd (1)

8-11: LGTM! Workflow sequence remains consistent.

The component renaming from Exocore to Imua maintains the same interaction flow and sequence of operations.

src/libraries/ActionAttributes.sol (1)

10-11:

✅ Verification successful

Verify the operation length changes.

The reduction in DELEGATION_OPERATION_LENGTH and ASSOCIATE_OPERATOR_LENGTH appears to be related to the shorter address prefix. These changes need verification to ensure they match the new message formats.

---

🏁 Script executed:

#!/bin/bash
# Search for any message length validations that might be affected
rg -A 3 "DELEGATION_OPERATION_LENGTH|ASSOCIATE_OPERATOR_LENGTH"

# Search for any message encoding/decoding logic
ast-grep --pattern 'function encode($$$) { $$$; }'

Length of output: 1326

---

Action Required: Operation Length Constants Verified

After reviewing the repository:

• The usage of DELEGATION_OPERATION_LENGTH (138) and ASSOCIATE_OPERATOR_LENGTH (74) in src/libraries/ActionAttributes.sol appears consistent. Both constants are directly used to assign messageLength for the corresponding actions.
• No discrepancies were found in any message encoding/decoding routines—the ast-grep search for an encode function returned no results, which indicates no conflicting logic.

These constant values now match the expected values based on the new message format (shorter address prefix). Please ensure that any external systems or unscanned parts of the codebase align with these changes.

test/foundry/TvlLimits.t.sol (2)

3-6: LGTM! Test dependencies correctly updated.

The import statements and contract inheritance have been properly updated to reflect the new Imua components while maintaining the same test structure.

Also applies to: 17-17

---

70-70:

❓ Verification inconclusive

Verify error message consistency.

The error message has been updated to reference Imuachain instead of Exocore. Ensure this error is consistently updated across all contracts.

---

🏁 Script executed:

#!/bin/bash
# Search for any remaining references to Exocore in error messages
rg "Exocore" --type sol

Length of output: 51

---

Attention: Verify error message consistency across all contracts

The error message in test/foundry/TvlLimits.t.sol (line 70) now correctly references Imuachain. However, the initial verification command failed due to an unrecognized file type. Please re-run the following command manually to ensure no lingering references to "Exocore" exist across the Solidity files:

rg "Exocore" -g "*.sol"

If any occurrences are found, update them to reference Imuachain accordingly.

test/mocks/DelegationMock.sol (1)

41-43:

❓ Verification inconclusive

Verify the new operator address length requirement.

The validation has been changed to require 41 bytes for operator addresses. Please ensure this matches Imua's address format specification.

Also applies to: 63-65

---

🌐 Web query:

What is the standard address length for Imua blockchain addresses?

💡 Result:

The provided search results do not contain any specific information about "Imua blockchain addresses." None of the sources mention Imua blockchain or its address formats.

For reference:

• Bitcoin addresses typically range from 26-35 alphanumeric characters depending on format (Legacy P2PKH, SegWit Bech32, etc.)[1][6][8]
• Ethereum addresses are 42-character hexadecimal strings starting with "0x"[2][8]

Without documentation about Imua blockchain in the search results, I cannot confirm its address specifications. You would need to consult Imua's official technical documentation or trusted blockchain explorers specific to this network for authoritative details about its address structure and length requirements.

Citations:

• 1: https://cointelegraph.com/learn/articles/types-of-bitcoin-addresses
• 2: https://www.ledger.com/academy/topics/blockchain/what-is-a-crypto-wallet-address
• 3: https://www.serviceobjects.com/blog/character-limits-in-address-lines-for-usps-ups-and-fedex/
• 4: https://www.blockchain.com/explorer
• 5: https://tangem.com/en/blog/post/what-are-the-address-types-and-how-do-they-differ/
• 6: https://bitflyer.com/en-us/s/glossary/address
• 7: https://www.investopedia.com/terms/p/private-key.asp
• 8: https://transak.com/blog/what-is-a-wallet-address-a-beginners-guide-to-crypto-wallet-addresses
• 9: https://learnmeabitcoin.com/technical/keys/address/
• 10: https://docs.tatum.io/docs/virtual-accounts

---

Confirm Operator Address Byte Length Validation

The current code enforces that operatorAddr has a length of 41 bytes in two places (test/mocks/DelegationMock.sol lines 41-43 and 63-65). However, our web search did not return any official documentation for Imua blockchain address formats to confirm if 41 bytes is indeed the correct requirement. Please verify this length against Imua's official technical documentation or a trusted source to ensure that the address validation is appropriate.

src/interfaces/IImuachainGateway.sol (1)

7-13: Documentation updates look good!

The interface documentation has been properly updated to reflect the Imua branding while maintaining clear and accurate descriptions of the functionality.

script/8_RegisterValidatorsAndDelegate.s.sol (1)

18-18: Variable renaming is consistent.

The renaming from exoAddresses to imAddresses has been applied consistently throughout the file, maintaining the original functionality while aligning with the Imua branding.

Also applies to: 38-38, 46-47, 68-69, 101-102

script/12_RedeployClientChainGateway.s.sol (2)

76-77: Verify owner address permissions.

The initialization now uses owner.addr instead of the previous validator set address. Please ensure the owner address has the necessary permissions for gateway initialization.

---

11-11:

❓ Verification inconclusive

Verify the initialization parameters.

The changes from Exocore to Imua have been applied consistently. However, please ensure:

1. The imuachainChainId matches the correct chain ID for the Imua network
2. The imuaCapsuleBeacon address is correctly configured

Run this script to verify the chain ID configuration:

Also applies to: 59-59, 63-63, 66-66

---

🏁 Script executed:

#!/bin/bash
# Description: Check for chain ID configuration in environment files and constants

# Search for chain ID definitions
rg -A 2 'chainId|CHAIN_ID' --glob '!*.lock'

Length of output: 65831

---

Initialization Parameters Verification

The switch from Exocore to Imua has been applied consistently. However, please confirm the following manually:

• Verify that the imuachainChainId in your deployment configuration reflects the correct chain ID for the Imua network. The environment output shows a reference to a chain ID (e.g. 232 in docs/btc-staking-e2e-testing.md); ensure that this is the intended value for Imua or update it accordingly.
• Confirm that the imuaCapsuleBeacon address is correctly set as per your latest deployment requirements.

script/13_DepositValidator.s.sol (1)

3-5: LGTM! Import statements and variable names updated consistently.

The changes align with the rebranding effort from Exocore to Imua, maintaining consistent naming across imports and variables without modifying the underlying functionality.

Also applies to: 52-60

src/core/BaseRestakingController.sol (1)

4-5: LGTM! Import statements, function names, and comments updated consistently.

The changes align with the rebranding effort from Exocore to Imua, maintaining consistent naming across imports, functions, and comments without modifying the underlying functionality.

Also applies to: 47-48, 93-93, 103-104, 117-120

script/BaseScript.sol (1)

3-5: LGTM! Import statements, struct members, and variables updated consistently.

The changes align with the rebranding effort from Exocore to Imua, maintaining consistent naming across imports, struct members, and variables without modifying the underlying functionality.

Also applies to: 36-37, 44-44, 52-54, 59-59, 71-71, 73-73, 77-77, 85-86, 92-96, 106-107, 110-110, 121-121

src/storage/ImuachainGatewayStorage.sol (1)

8-11: LGTM! Contract name, event names, and comments updated consistently.

The changes align with the rebranding effort from Exocore to Imua, maintaining consistent naming across the contract name, event names, and comments without modifying the underlying functionality.

Also applies to: 42-42, 104-104

src/core/ClientChainGateway.sol (3)

28-29: LGTM! Updated author attribution.

The author attribution has been correctly updated to reflect the new organization.

---

110-110: LGTM! Updated error message.

The error message has been correctly updated to align with the new branding.

---

132-132: LGTM! Updated chain ID reference.

The chain ID reference has been correctly updated to use the new constant.

script/14_CorrectBootstrapErrors.s.sol (3)

13-13: LGTM! Updated import statement.

The import statement has been correctly updated to use the new contract name.

---

80-80: LGTM! Updated error message.

The error message has been correctly updated to reflect the new contract name.

---

82-82: LGTM! Updated initialization and configuration parameters.

The initialization and configuration parameters have been correctly updated to use the new addresses and chain IDs.

Also applies to: 95-95, 98-98

script/7_DeployBootstrap.s.sol (2)

9-9: LGTM! Updated import statement.

The import statement has been correctly updated to use the new contract name.

---

69-69: LGTM! Updated contract instantiation and configuration.

The contract instantiation, configuration parameters, and initialization have been correctly updated to use the new contract names and addresses.

Also applies to: 77-77, 80-80, 96-96, 108-108

script/17_WithdrawalValidator.s.sol (2)

3-9: LGTM! Updated import statements.

The import statements have been correctly updated to use the new contract and interface names.

---

61-71: LGTM! Updated variable references and comments.

The variable references and comments have been correctly updated to reflect the new branding.

src/core/ClientGatewayLzReceiver.sol (5)

4-4: LGTM: Import statement updated correctly.

The import statement has been correctly updated from IExoCapsule to IImuaCapsule as part of the rebranding.

---

16-17: LGTM: Author and notice comments updated correctly.

The author and notice comments have been correctly updated to reflect the new branding:

• Author changed from ExocoreNetwork to imua-xyz
• Notice updated to reference "Imuachain Gateway" instead of "Exocore Gateway"

---

46-46: LGTM: Chain ID reference updated correctly.

The chain ID reference has been correctly updated from EXOCORE_CHAIN_ID to IMUACHAIN_CHAIN_ID in the source chain validation.

---

70-74: LGTM: Comments updated correctly.

The comments have been correctly updated to reference "Imuachain" instead of "Exocore" in the function and contract documentation.

---

154-154: LGTM: Interface reference updated correctly.

The interface reference has been correctly updated from IExoCapsule to IImuaCapsule in the function implementation.

test/foundry/Delegation.t.sol (3)

3-3: LGTM: Import statements updated correctly.

The import statements have been correctly updated to reference the new Imua contracts:

• ImuachainGateway.sol instead of ExocoreGateway.sol
• ImuachainDeployer.t.sol instead of ExocoreDeployer.t.sol

Also applies to: 8-8, 15-15

---

57-57: LGTM: Operator address updated correctly.

The operator address has been correctly updated from an Exocore address to an Imua address format.

---

105-105: LGTM: Gateway references updated correctly.

The gateway references have been correctly updated to use imuachainChainId, imuachainGateway, and related variables.

Also applies to: 191-193

test/hardhat/integration/btc-stake.test.js (2)

41-41: LGTM: Operator address constant updated correctly.

The operator address constant has been correctly updated from an Exocore address format to an Imua address format.

---

146-146: LGTM: Field name updated correctly.

The field name in the stake message has been correctly updated from exocoreAddress to imuachainAddress to reflect the new branding.

Also applies to: 168-168

test/foundry/DepositThenDelegateTo.t.sol (4)

3-3: LGTM: Import statements updated correctly.

The import statements have been correctly updated to reference the new Imua contracts:

• ImuachainGateway.sol instead of ExocoreGateway.sol
• ImuachainDeployer.t.sol instead of ExocoreDeployer.t.sol

Also applies to: 10-10

---

18-18: LGTM: Contract inheritance and comments updated correctly.

The contract inheritance and comments have been correctly updated:

• Contract now extends ImuachainDeployer instead of ExocoreDeployer
• Comments updated to reference "ImuachainGateway" instead of "ExocoreGateway"

Also applies to: 22-22

---

48-48: LGTM: Operator addresses updated correctly.

All operator addresses have been correctly updated from Exocore address format to Imua address format throughout the test file.

Also applies to: 76-76, 226-226, 244-244, 254-254, 281-281

---

99-99: LGTM: Comments updated correctly.

The comments have been correctly updated to reference "Imuachain" instead of "Exocore" in the test documentation.

Also applies to: 150-150

script/hardhat/deploy-and-setup-utxogateway.script.js (1)

24-27:

❓ Verification inconclusive

Verify all references have been updated consistently.

The renaming from exocore to imuachain has been applied consistently in the deployment script. However, let's ensure no references were missed.

Also applies to: 84-87, 188-193

---

🏁 Script executed:

#!/bin/bash
# Description: Search for any remaining references to 'exocore' in the codebase

# Search for any remaining 'exocore' references (case-insensitive)
rg -i 'exocore' --type js

Length of output: 25

---

Manual Verification Required for Consistent Reference Updates

The automated search for "exocore" using ripgrep (with rg -i 'exocore' --type js) returned no results in JavaScript files—which suggests that the renaming to "imuachain" has been applied. However, because the output was empty and might not fully capture all cases, please manually verify that all instances (including in the file script/hardhat/deploy-and-setup-utxogateway.script.js at lines 24–27, 84–87, and 188–193) have been updated consistently.

test/foundry/Governance.t.sol (1)

26-26: LGTM!

The renaming from ExoCapsule to ImuaCapsule and related references has been implemented consistently throughout the file. The changes maintain the original functionality while aligning with the new naming convention.

Also applies to: 33-33, 71-71, 77-77, 158-158, 161-161

src/libraries/Errors.sol (1)

7-8: LGTM!

The error messages and comments have been updated consistently to reflect the rebranding from "Exocore" to "Imua". The changes maintain the original error handling functionality while aligning with the new naming convention.

Also applies to: 86-86, 160-162, 181-185, 192-195, 208-209, 211-218, 221-234, 237-240, 258-258

test/foundry/BootstrapDepositNST.t.sol (3)

13-13: LGTM: Import statement updated correctly.

The import statement has been updated from ExoCapsule.sol to ImuaCapsule.sol as part of the rebranding effort.

---

38-38: LGTM: Variable names and types updated consistently.

The variable names and types have been updated consistently:

• exocoreChainId → imuachainChainId
• IExoCapsule → IImuaCapsule
• ExoCapsule → ImuaCapsule

Also applies to: 48-48, 52-52

---

84-84: LGTM: Function signatures and implementations updated correctly.

The function signatures and implementations have been updated to use the new types:

• Constructor call changed to ImuaCapsule
• Function parameter type changed to IImuaCapsule
• Variable type changed to ImuaCapsule

Also applies to: 286-290

src/storage/UTXOGatewayStorage.sol (2)

57-58: LGTM: Struct field and documentation updated consistently.

The struct field and its documentation have been updated to use the new terminology:

• Comment updated to reference "Imuachain"
• Field name changed from exocoreAddress to imuachainAddress

Also applies to: 66-66

---

110-111: LGTM: Constants updated correctly.

The constant and its documentation have been updated:

• Comment updated to reference "Imuachain"
• Constant name changed from EXO_ADDRESS_PREFIX to IMUA_ADDRESS_PREFIX
• Value changed from "exo1" to "im1"

src/core/ImuaCapsule.sol (3)

4-4: LGTM: Import statements updated correctly.

The import statements have been updated to use the new contract names:

• IExoCapsule → IImuaCapsule
• ExoCapsuleStorage → ImuaCapsuleStorage

Also applies to: 11-11

---

16-19: LGTM: Contract documentation updated consistently.

The contract documentation has been updated to use the new terminology:

• Title updated to "ImuaCapsule"
• Author updated to "imua-xyz"
• Description updated to reference "Imuachain"

---

148-150: LGTM: Error messages updated consistently.

The error messages have been updated to use the new contract name:

• Gateway address validation message
• Recipient address validation message
• NonBeaconChainETHBalance withdrawal message

Also applies to: 257-258, 277-279

src/storage/BootstrapStorage.sol (4)

9-9: LGTM: Import statement updated correctly.

The import statement has been updated from IExoCapsule to IImuaCapsule.

---

32-33: LGTM: Documentation updated consistently.

The documentation has been updated to use the new terminology:

• Updated spawn time description to reference Imuachain
• Updated offset duration description to reference Imuachain

Also applies to: 37-38

---

137-137: LGTM: Variable names updated consistently.

The variable names have been updated:

• EXO_CAPSULE_BEACON → IMUA_CAPSULE_BEACON
• EXOCORE_CHAIN_ID → IMUACHAIN_CHAIN_ID

Also applies to: 150-150

---

402-404: LGTM: Function documentation updated correctly.

The function documentation has been updated to use the new terminology:

• Updated return type description to reference ImuaCapsule
• Updated parameter description to reference ImuaCapsule

test/mocks/ImuachainGatewayMock.sol (1)

1-578: LGTM! The renaming changes are consistent throughout the mock contract.

The changes are part of the rebranding from Exocore to Imua, with consistent updates to contract names, error messages, and comments while maintaining the original functionality.

test/foundry/unit/ImuachainGateway.t.sol (1)

1-842: LGTM! Test coverage remains comprehensive after rebranding.

The test file has been properly updated to reflect the rebranding from Exocore to Imua while maintaining the same level of test coverage and functionality verification.

src/core/Bootstrap.sol (1)

1-850:

❓ Verification inconclusive

Verify storage layout compatibility after variable renaming.

The PR description mentions potential issues with storage layout checks in CI. This is likely due to the renaming of storage variables like ethToImAddress (previously ethToExoAddress). Storage layout changes can cause issues with upgradeable contracts.

Run the following script to check for storage layout compatibility:

---

🏁 Script executed:

#!/bin/bash
# Description: Check storage layout compatibility
# Note: This assumes the project uses hardhat or foundry for storage layout checks

# If using hardhat
if [ -f "hardhat.config.ts" ] || [ -f "hardhat.config.js" ]; then
    npx hardhat check
fi

# If using foundry
if [ -f "foundry.toml" ]; then
    forge inspect src/core/Bootstrap.sol:Bootstrap storage-layout --pretty
fi

Length of output: 1863

---

Action Required: Manually Verify Storage Layout Compatibility

The PR renames storage variables (e.g., changing ethToExAddress to ethToImAddress), which may affect the upgradeable contract's storage layout. The automated storage layout check did not produce valid output because Hardhat isn’t installed locally and Foundry wasn’t found, so the current verification is inconclusive.

• Ensure that Hardhat is installed locally (e.g., via npm or Yarn) and re-run the storage layout checks.
• Alternatively, set up Foundry to execute forge inspect src/core/Bootstrap.sol:Bootstrap storage-layout --pretty.
• Manually verify that the storage layout remains compatible after the renaming before merging the PR.

test/foundry/unit/UTXOGateway.t.sol (3)

12-12: LGTM!

The import statement has been correctly updated to reflect the rebranding from Exocore to Imuachain.

---

25-25: LGTM!

The constant and variable names have been correctly updated to reflect the rebranding from Exocore to Imuachain.

Also applies to: 41-41

---

64-64: LGTM!

The event parameter names and error names have been correctly updated to reflect the rebranding from Exocore to Imuachain.

Also applies to: 69-69, 79-79, 92-92, 99-99, 107-107, 115-115, 694-694, 750-750, 772-772, 793-793, 815-815, 851-851, 889-889, 932-932, 957-957, 977-977, 1003-1003, 1014-1014, 1062-1062, 1091-1091, 1135-1135, 1160-1160, 1183-1183, 1225-1225, 1245-1245

script/deployments/testContracts.json (1)

2-4: LGTM!

The JSON keys have been correctly updated to reflect the rebranding from Exocore to Imuachain while maintaining the same values for the gateway and endpoint.

script/deployments/deployedExocoreGatewayOnly.json (1)

2-6: LGTM!

The JSON keys have been correctly updated to reflect the rebranding from Exocore to Imuachain while maintaining the same values for the gateway, gateway logic, proxy admin, and endpoint.

script/deployments/prerequisiteContracts.json (1)

9-9: LGTM!

The JSON key has been correctly updated to reflect the rebranding from Exocore to Imuachain while maintaining the same value for the endpoint.

package.json (3)

2-2: Rebranding Update: Package Name Change
The package name has been updated to "imua-contracts", which is fully in line with the new branding requirements.

---

4-4: Rebranding Update: Updated Package Description
The description now clearly states the repository’s new purpose within the Imuachain ecosystem.

---

13-13: Rebranding Update: Deployment Script Command Modified
The deployment command now uses the imuachain_localnet network, ensuring consistency with the environment variable changes.

foundry.toml (2)

40-41: Rebranding Update: RPC Endpoints Revised
The RPC endpoints have been updated from the Exocore identifiers to imuachain_localnet and imuachain_testnet, aligning with the new environment variable names.

---

54-54: Rebranding Update: Etherscan Configuration Updated
The Etherscan entry now points to the Imuachain testnet explorer, which is essential for consistent deployments and verifications.

script/deployments/deployedContracts.json (1)

34-38: Rebranding Update: Replaced Exocore with Imuachain Section
The old "exocore" section has been replaced by a new "imuachain" section. The structure and values remain intact, ensuring a smooth transition in contract configurations.

docs/summary.md (5)

5-6: Rebranding Update: Added ImuachainGateway Documentation Section
The new section for ImuachainGateway accurately describes its role in handling cross-chain messaging and aligns with the overall rebranding effort.

---

12-12: Rebranding Update: BaseRestakingController Description Revised
The text now clearly indicates that the contract’s operations relate to Imuachain, maintaining consistency across the documentation.

---

15-15: Rebranding Update: LSTRestakingController Description Revised
The description now properly reflects that its operations (such as token deposits and reward withdrawals) are performed in the context of Imuachain.

---

18-18: Rebranding Update: NativeRestakingController Description Revised
The updated description correctly clarifies its role in Ethereum restaking and highlights the creation of ImuaCapsule contracts, in line with the new branding.

---

23-24: Rebranding Update: ImuaCapsule Documentation Added
The new section for ImuaCapsule clearly outlines its functionality in managing native restaking tokens. This update reinforces the shift in branding from Exocore to Imua.

README.md (4)

1-1: Rebranding Update: Repository Title Changed
The title has been updated to "# Imua Contracts", immediately reflecting the new brand identity.

---

3-3: Rebranding Update: Repository Description Revised
The updated description now correctly specifies that the smart contracts are deployed on Imuachain, ensuring clarity for users.

---

34-34: Rebranding Update: Git Clone Command Modified
The git clone command now references imua-xyz/imua-contracts, ensuring consistency with the new repository naming structure.

---

72-76: Rebranding Update: Deployment Addresses Section Updated
The links and branch references in this section have been modified to point to the updated repository and deployment data, ensuring users access the correct resources.

.env.example (3)

3-4: Rebranding of RPC Environment Variables.
The new variables IMUACHAIN_TESTNET_RPC and IMUACHAIN_LOCALNET_RPC correctly replace the previous Exocore variants and both point to the expected local RPC URL.

---

10-11: Updated Genesis Key and Export Command.
The private key export command and the genesis private key variable have been updated from EXOCORE to IMUACHAIN. Please verify that these sensitive values are handled securely in production.

---

14-14: Updated Precompile Mock Setting.
The variable USE_IMUACHAIN_PRECOMPILE_MOCK is now used instead of the EXOCORE one. This update looks consistent with the rebranding effort.

docs/contracts-owner-manual.md (3)

3-4: Contract Ownership Rebranding Update.
The introduction now correctly lists the contracts (including ImuachainGateway) under the rebranded system. All references appear consistent; ensure that the rest of the documentation and code also follow this new naming.

---

13-14: Upgrade Process Documentation.
The section on upgrading now correctly references ProxyAdmin, ImuachainGateway, and ImuaCapsule. It would be good to verify that any cross-referenced implementation details in the code and tests are updated accordingly.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~13-~13: A comma might be missing here.
Context: ... ## upgrade to new implementation Most contracts including Bootstrap, `ClientChainGate...

(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)

---

20-22: Token Whitelist Update.
The updated explanation regarding token whitelist additions now clearly indicates that no cross-chain message is sent upon metadata updates. This is consistent with the rebranding.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~20-~20: You might be missing the article “the” here.
Context: ...r contract. ## add or update tokens to whitelist Another important task before restakin...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

---

[uncategorized] ~22-~22: You might be missing the article “the” here.
Context: ...ing being activated is to add tokens to whitelist to mark them as stake-able on both Imua...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

docs/ClientChainGateway.md (7)

3-4: Introduction Update.
The introduction now clearly states that the ClientChainGateway interacts with Imua. It correctly outlines cross-chain messaging with the new network.

---

15-16: Updated Deposit Operations.
The deposit operations now specify that tokens are deposited to Imua and that such deposits always “succeed” on Imuachain. This aligns with the system’s design; please ensure that any potential error cases are documented elsewhere if needed.

---

28-29: Delegation Details with Imuachain.
The delegation section now includes that cross-chain messages and the corresponding delegation accounting are handled on Imuachain. This change is in line with the overall rebranding.

---

43-44: API Renaming Consistency.
The function formerly known as claimPrincipalFromExocore is now renamed to claimPrincipalFromImuachain, which is clear and consistent. Confirm that downstream calls and tests have been updated accordingly.

---

61-62: ImuaCapsule Creation Function.
The renaming from createExoCapsule() to createImuaCapsule() is well applied. Verify that the system deployment scripts and contract deployments reflect this change to avoid mismatches.

---

76-80: Native Stake Verification Update.
The description of the verifyAndDepositNativeStake function now mentions sending a message to Imuachain correctly. It may be useful to add a brief note on the updated relay fee requirements if not already documented elsewhere.

---

91-92: Withdrawal Operation Consistency.
The withdrawal process now correctly references post-claim steps on Imuachain. Ensure that any related contract and integration tests align with these updated steps.

docs/btc-staking-e2e-testing.md (6)

19-21: Repository URL Update for Esplora.
The Esplora cloning command now correctly uses the repository under imua-xyz, which reflects the new branding. Ensure all documentation referring to the old URL has been updated.

---

45-53: Imuachain Node Setup Updated.
The steps for cloning and switching to the imuachain repository (using the develop branch) are clearly updated. Verify that the local node’s configuration matches these new settings.

---

65-69: UTXO Gateway Deployment Instructions.
The instructions for cloning and running the UTXO gateway contract from imua-contracts are now in line with the rebranding. Please confirm that deployment scripts and environment configurations use the updated naming.

---

73-79: Updated Hardhat Configuration.
The Hardhat configuration now uses the environment variable LOCAL_IMUACHAIN_FUNDED_ACCOUNT_PRIVATE_KEY. Verify that this variable’s value is set correctly in the local .env file and that it integrates with the deployment process as expected.

---

127-127: Test Configuration Advisory.
The notice to set MIN_CONFIRMATIONS to 1 is clear; just confirm that this recommendation works well with the Imuachain parameters for testing without introducing timeouts.

---

154-155: End-to-End Test Simulation Clarification.
The summary of the test simulation (building a valid Bitcoin deposit transaction, broadcasting, and verifying the staker’s balance on Imuachain) is comprehensive. Ensure that all test scripts and environment variables are updated alongside these instructions.

docs/reward-vault.md (4)

5-6: Reward Vault Rebranding Update.
The introduction now clearly describes the Reward Vault as part of the rebranded IMUA system and aligns with the updated reward distribution process.

---

42-44: ClientChainGateway Function Update.
The renaming of the Gateway function to claimRewardFromImuachain is clearly documented in this section. Please ensure that the corresponding contract code and tests have been updated similarly.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~44-~44: Loose punctuation mark.
Context: ...muachain(address token, uint256 amount)`: Initiates a claim request to Imuachain....

(UNLIKELY_OPENING_PUNCTUATION)

---

146-147: Consistency in Documented Interfaces.
The later sections (covering events and upgradeability) now consistently match the rebranded function names and process flows. This detailed documentation is helpful; a final proofread for minor punctuation or grammatical issues is recommended.

---

157-159: Overall Reward Vault Documentation.
The document now thoroughly covers the reward submission, distribution, and claiming process under Imuachain. Minor punctuation suggestions noted above can be addressed in an editorial pass.

.github/workflows/forge-ci.yml (2)

208-214: Ensure Renaming Consistency in Contract Artifact JSON.
The change from the old contract name to ImuaCapsule in the validated contracts JSON (line 213) correctly reflects the rebranding. Verify that downstream tools and workflows consuming this artifact expect the new key name.

---

230-248: Confirm Matrix Strategy Updates for New Contract Names.
The extract-storage-layout job matrix now includes updated contract names such as ImuachainGateway and ImuaCapsule for both base and non-base cases. Ensure that these entries match the new naming conventions across the codebase and that the appropriate build steps handle both base branch and PR contexts properly.

docs/client-chain-contracts-design.md (3)

5-6: Consistent Rebranding in Overview Section.
The introductory paragraph now uses “Imua” instead of the old name and clearly explains the role of the client chain smart contracts. Ensure that future modifications retain this consistency throughout all documentation sections.

---

114-124: Correct Update of Function Signature for Cross-Chain Messaging.
The function signature change from _sendMsgToExocore to _sendMsgToImuachain is properly reflected in the code snippet. Make sure that all internal references and documentation in the code and tests are updated accordingly to avoid any discrepancies.

---

125-131: Accurate Rebranding in Documentation Sections.
The section headings and descriptions (e.g. for _sendMsgToImuachain and _lzReceive) now reflect the new system names. Verify that the language throughout (including subsequent sections describing deposit/withdraw flows) remains consistent with the new terminology.

docs/cross-chain-communication-model.md (1)

1-6: Updated Terminology in Cross-Chain Communication Model.
The document now refers to the “Imuachain” correctly and aligns the narrative with the broader rebranding effort. Ensure that phrases such as “ImuachainGateway” consistently match the new naming convention.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~5-~5: You might be missing the article “the” here.
Context: ... the client chains and forwards them to Imuachain chain, or sends requests to the client ...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

src/storage/ImuaCapsuleStorage.sol (5)

11-13: Documentation Updated to Reflect New Brand Identity.
The header comments (title, author, and notice) now correctly use “ImuaCapsuleStorage” and reference “imua-xyz”. This improves clarity for developers and users alike.

---

27-30: Update in Validator Documentation.
The comment for the Validator struct now states “in the ImuaCapsule,” which aligns with the overall rebranding. Confirm that any external documentation referencing validator status is updated accordingly.

---

71-73: Consistent Ownership Field Naming.
The comment on the capsuleOwner variable now correctly refers to the “ImuaCapsule,” ensuring consistency with the contract’s new identity.

---

93-97: Constructor Documentation Accurately Reflects Configuration.
The constructor’s documentation has been updated to state that it sets the network configuration for the ImuaCapsule contract. This clearly communicates its purpose, ensuring that any changes in network parameters are handled appropriately.

---

1-136: Overall Code Structure and Naming Conventions.
The renaming across the smart contract—from contract names to inline comments—appears to be thorough and consistent. Additionally, the static analysis hint regarding CapWords for contract names is satisfied with ImuaCapsuleStorage.

🧰 Tools

🪛 GitHub Check: lint

[warning] 20-20:
Contract, Structs and Enums should be in CapWords

Reviewing files that changed from the base of the PR and between db4cd66 and 90fa8fe.

• docs/client-chain-contracts-design.md (7 hunks)
• docs/reward-vault.md (6 hunks)
• script/deployments/deployedImuachainGatewayOnly.json (1 hunks)
• src/core/ImuachainGateway.sol (14 hunks)
• test/foundry/DepositWithdrawPrincipal.t.sol (28 hunks)
• test/hardhat/integration/btc-stake-e2e.test.js (1 hunks)

• script/deployments/deployedImuachainGatewayOnly.json

• test/hardhat/integration/btc-stake-e2e.test.js

• GitHub Check: analyze

test/foundry/DepositWithdrawPrincipal.t.sol (2)

3-4: LGTM! Import statements and contract declaration are correctly updated.

The changes consistently reflect the rebranding from Exocore to Imua while maintaining the same functionality.

Also applies to: 7-7, 11-11, 18-18

---

39-786: LGTM! Test functions and helper methods are correctly updated.

The test functions and helper methods have been consistently updated to use the new terminology while preserving the original test coverage and functionality.

src/core/ImuachainGateway.sol (2)

4-4: LGTM! Contract rebranding looks good.

The contract has been correctly renamed from ExocoreGateway to ImuachainGateway, including all imports, inheritance, and documentation.

Also applies to: 20-20, 34-46

---

305-305:

❓ Verification inconclusive

Consider adding reentrancy protection for nonce management.

The contract uses nonce management for cross-chain message ordering, but there's no explicit protection against reentrancy in the nonce update logic. While the contract inherits from ReentrancyGuardUpgradeable, it's good practice to have additional safeguards for critical state changes.

Let's verify the nonce update implementation in the parent contract:

Also applies to: 584-584

---

🏁 Script executed:

#!/bin/bash
# Search for _verifyAndUpdateNonce implementation
ast-grep --pattern $'function _verifyAndUpdateNonce($_) {
  $$$
}'

Length of output: 67

---

Action Required: Manual Verification of Nonce Update and Missing Functionality

The automated search did not provide evidence of the _verifyAndUpdateNonce implementation, nor did it indicate the presence of the functions fixReentrance and fixNonce mentioned in the AI summary. This leaves ambiguity regarding their expected locations or implementations. Please manually verify the following:

• Confirm whether a definition for _verifyAndUpdateNonce exists in a parent contract or elsewhere in the repository.
• Check if the functions fixReentrance and fixNonce have been intentionally removed or integrated differently, as they are not found during general code searches.
• Evaluate if additional reentrancy safeguards for nonce updates are necessary despite the current inheritance from ReentrancyGuardUpgradeable.

docs/reward-vault.md (5)

15-15: Clarified Source of Truth
The updated description clearly assigns Imuachain as the source of truth for reward balances and distribution. This aligns with the refactoring objectives and clarifies system responsibility.

---

124-125: Reward Submission Process Clarity
The updated steps in the “Reward Submission” section now explicitly indicate that:
• The Gateway sends a message to Imuachain and
• Imuachain processes the request, emitting a RewardOperationResult event
These changes improve clarity regarding the flow of actions.

---

129-130: Reward Distribution and Accounting Update
The modifications in the “Reward Distribution and Accounting” section correctly reflect that Imuachain is handling both the distribution process and the tracking of staker rewards. This updated narrative is clear and consistent with the overall rebranding.

---

134-136: Clear Reward Claim Process Update
The revised steps for reward claiming—from the staker’s call to claimRewardFromImuachain through to the verification by Imuachain—are well documented. The process flow is now clear and aligns with the new operational model.

---

151-151: Access Control on Claim Function
The updated note specifying that only stakers should call ClientChainGateway.claimRewardFromImuachain for their own rewards is an important security detail. Please ensure that the corresponding contract implementation enforces this precisely.

docs/client-chain-contracts-design.md (13)

5-5: Branding Update and Clarity
The opening description now consistently uses “Imua” (e.g., “Imua client chain smart contracts” and “Imua users”), which aligns with the rebranding efforts. Please verify that this language is uniformly applied across all related documentation.

---

10-10: Bullet Item 2: Rebranding Consistency
The second bullet now references forwarding user requests to Imuachain. This update appears consistent and clear.

---

12-12: Updated Component Introduction
The introduction to the component list now accurately reflects the rebranded architecture by stating “Imua client chain smart contracts architecture.” This helps set the correct context for the subsequent bullet points.

---

109-109: Governance Ownership Description
The sentence now explains that eventually the governance system of Imuachain should own the ClientChainGateway. This update is clear; just ensure that the intended ownership and upgrade rights are documented consistently across contracts and interfaces.

---

115-119: Function Signature Update for _sendMsgToImuachain
The documentation and function signature have been updated from _sendMsgToExocore to _sendMsgToImuachain in the BaseRestakingController. This is an important update for ensuring that all external and internal references match the new branding. Please verify that related contract calls, tests, and documentation references have also been updated accordingly.

---

230-233: Function Signature Update for claimRewardFromImuachain
The function signature and accompanying notice have been correctly updated to reflect the rebranding—from claimRewardFromExocore to claimRewardFromImuachain. Ensure that all associated interfaces and tests reflect this change.

---

248-248: Cross-Chain Message Processing Clarity
The explanation for the deposit process—detailing the asynchronous cross-chain message sent to Imuachain—is clear and aligns well with the system design.

---

254-254: Delegation Workflow Explanation
The description for the delegation workflow now indicates that a single transaction is sufficient to send a delegate request to Imuachain, with no expected immediate response. This is clearly articulated.

---

260-260: Undelegation Process Description
The updated text explains the necessity of an unbonding period before undelegation is released for withdrawal. This description is clear and consistent with the intended process.

---

262-262: Claim Principal Heading Update
The heading “### claimPrincipalFromImuachain” correctly reflects the rebranding and function purpose.

---

264-264: Claim Principal Process Details
The documentation now outlines the process for claiming principal from Imuachain to the client chain and updating the user’s balance accordingly. The details are clearly described; just ensure that the language captures all necessary edge cases.

---

268-269: Principal Withdrawal Workflow Explanation
The two-step process for principal withdrawal—initiated by a cross-chain message followed by a response that triggers a balance update—is well explained. Confirm that this asynchronous flow is consistent with other sections of the documentation.

---

279-279: Withdrawal Function Details
The description for the withdrawal function clearly explains that users must ensure sufficient unlocked principal before initiating a withdrawal. This detail is important for security and correctness.

Reviewing files that changed from the base of the PR and between 90fa8fe and 1038ac4.

• src/core/ImuachainGateway.sol (14 hunks)

• GitHub Check: analyze

src/core/ImuachainGateway.sol (2)

36-43: LGTM! Robust security measures implemented.

The contract implements essential security features through OpenZeppelin contracts:

• PausableUpgradeable for emergency stops
• OwnableUpgradeable for access control
• ReentrancyGuardUpgradeable for preventing reentrancy attacks

---

1-585: Document emergency functions and their implications.

Based on previous review comments, this contract includes emergency functions for direct storage manipulation. These functions and their implications should be clearly documented:

1. When and why they would be used
2. The potential risks
3. The recovery process
4. Whether they are temporary or permanent solutions

Reviewing files that changed from the base of the PR and between bfb5a63 and 4178f62.

• .gitmodules (1 hunks)
• foundry.toml (2 hunks)
• lib/create3-factory (1 hunks)
• script/22_DeployLibrary.s.sol (1 hunks)
• script/7_DeployBootstrap.s.sol (5 hunks)
• script/deployments/deployedContracts.json (2 hunks)
• script/deployments/libraries.json (1 hunks)
• script/hardhat/deploy-and-setup-utxogateway.script.js (5 hunks)
• src/storage/BootstrapStorage.sol (15 hunks)

• lib/create3-factory
• script/deployments/libraries.json
• .gitmodules

• script/hardhat/deploy-and-setup-utxogateway.script.js
• foundry.toml

script/deployments/deployedContracts.json (3)

5-9: Verify Updated ClientChain Bootstrap and Logic Addresses

The new hexadecimal values for the keys "bootstrap", "bootstrapLogic", "capsuleBeacon", "capsuleImplementation", and "clientGatewayLogic" have been updated as part of the rebranding. Please ensure these values correctly correspond to the new deployments and update any dependent configurations (e.g., storage layout checks in CI) accordingly.

---

11-15: Confirm Updated ClientChain Administrative and Vault Addresses

The addresses for "proxyAdmin", "rewardVaultBeacon", "rewardVaultImplementation", "vaultBeacon", and "vaultImplementation" have been modified. Verify that these new values match the intended deployment targets in the rebranded setup and that all related systems (such as deployment scripts and CI checks) have been updated to reference these changes.

---

34-37: Review Addition of the New "imuachain" Section

A new section "imuachain" has been introduced replacing the legacy "exocore" references. The updated entries for "imuachainGateway", "imuachainGatewayLogic", and "imuachainProxyAdmin" should be cross-checked with the deployment artifacts to ensure consistency. Additionally, confirm that all CI configurations—especially storage layout checks—and documentation have been updated to recognize the new imuachain branding.

src/storage/BootstrapStorage.sol (4)

9-9: Consistent rebranding from "Exocore" to "Imua/Imuachain" throughout the file.

The changes consistently rename all references from "Exocore" to "Imua" or "Imuachain" across import statements, state variables, mapping names, documentation comments, constructor parameters, and function return types. This aligns with the overall rebranding effort mentioned in the PR objectives.

Also applies to: 23-24, 32-33, 37-38, 46-46, 50-53, 54-57, 60-62, 68-68, 94-95, 99-99, 137-138, 149-150, 181-183, 186-186, 192-194, 197-198, 223-223, 234-234, 245-245, 256-259, 293-296, 320-320, 323-323, 328-328, 331-331, 369-370, 376-376, 379-379, 402-406

---

23-24: Authorship updated to reflect new brand.

The @author tag has been updated to "imua-xyz". Ensure this is consistent with the organization's new branding strategy.

---

9-9:

✅ Verification successful

Ensure the IImuaCapsule interface file exists and is properly renamed.

The import statement has been updated from IExoCapsule to IImuaCapsule. Make sure the corresponding interface file has been properly renamed and that all method signatures remain compatible.

---

🏁 Script executed:

#!/bin/bash
# Check if the IImuaCapsule.sol file exists and compare it with any backup or git history of IExoCapsule.sol
fd -t f "IImuaCapsule.sol" -x echo "IImuaCapsule file exists: {}"

Length of output: 125

---

Interface file confirmed; verify signature compatibility as needed

The IImuaCapsule interface file has been located at ./src/interfaces/IImuaCapsule.sol. Please ensure that the interface’s method signatures match those of the previous IExoCapsule interface to maintain compatibility.

---

369-370:

❓ Verification inconclusive

Verify storage layout compatibility with existing deployments.

The change of immutable variable names (from EXOCORE_CHAIN_ID to IMUACHAIN_CHAIN_ID and similar) shouldn't affect storage layout since immutable variables are not stored in contract storage. However, given the concern mentioned in the PR objectives about "potential issues with the storage layout check in CI," you should verify this doesn't cause deployment issues.

Also applies to: 376-376, 379-379

---

🏁 Script executed:

#!/bin/bash
# Check if there are storage layout compatibility tests in the codebase
rg -l "storage layout|StorageLayout" --type-add "yml:*.yml" --type yml
rg -l "storage layout|StorageLayout" --type-add "yaml:*.yaml" --type yaml
rg -l "storage layout|StorageLayout" --type js
rg -l "storage layout|StorageLayout" --type ts

Length of output: 693

---

Action: Manually Verify Storage Layout Compatibility

The renaming of immutable variables (e.g., from EXOCORE_CHAIN_ID to IMUACHAIN_CHAIN_ID) should not impact the contract's storage layout since immutable variables aren’t stored. However, given the PR’s objective to rule out potential CI-related storage layout issues—and based on our inability to automatically locate relevant storage layout tests—we recommend a manual verification to ensure that no deployment issues arise from these changes.

• Confirm that the deployment process or any CI checks aren’t indirectly relying on the old naming.
• Verify manually that similar changes on lines 376 and 379 also do not cause side effects.

script/22_DeployLibrary.s.sol (3)

1-6: Import dependencies look appropriate.

The imports properly include the CREATE3 factory, NetworkConstants library, and BaseScript base class needed for the deployment process.

---

1-36: Overall script structure looks appropriate for library deployment.

The script properly handles the deployment of the NetworkConstants library using the CREATE3 pattern, which ensures deterministic addresses. The basic structure follows good practices for Foundry deployment scripts.

---

28-31:

❓ Verification inconclusive

Verify network constants are being recorded properly.

The serialization process only writes the address under "sepolia", but it's not clear if this script is intended to run on multiple networks. Ensure the network information is appropriately captured in the output JSON.

---

🏁 Script executed:

#!/bin/bash
# Check if there are other network configurations in the codebase
echo "Checking for network configurations in the script folder..."
grep -r "clientChain" --include="*.sol" script/
echo "Checking for network constants in JSON files..."
find script/deployments -name "*.json" -type f -exec cat {} \; | grep -o "\"[a-zA-Z]*\"\\s*:" | sort | uniq

Length of output: 23793

---

Network Constant Serialization – Confirm Multi-Network Intent

In file script/22_DeployLibrary.s.sol (lines 28–31), the library address is serialized exclusively under the "sepolia" key:

        string memory subkey = vm.serializeAddress("sepolia", "networkConstants", libraryAddress);
        string memory finalJson = vm.serializeString("libraries", "sepolia", subkey);

Please verify whether this is intentional. If the deployment is meant to support only the sepolia network, then it may be helpful to add a comment documenting that decision. However, if multi-network support (for example, including a "clientChain" key similar to other scripts) is required, the output JSON should be updated accordingly to capture the proper network configuration.

script/7_DeployBootstrap.s.sol (8)

9-9: Renamed import rebranding looks correct.
No issues found regarding the switch from ExoCapsule to ImuaCapsule.

---

24-25: Import for CREATE3_FACTORY aligns with the usage below.
No immediate issues.

---

29-29: Salt declaration is appropriate for deterministic deployments.
This maintains clarity by explicitly storing the salt.

---

63-63: Double-check the security of private keys in your deployment scripts.
Make sure the owner.privateKey is safe for test or local usage only.

---

78-78: Implementation rename is consistent.
The switch to new ImuaCapsule(address(0)) looks correct, matching the updated contract name.

---

86-86: Renaming to imuachainChainId is straightforward.
No further issues with the updated struct field.

---

89-89: Renaming to imuaCapsuleBeacon mirrors the new contract naming scheme.
Change is consistent with the rebranding.

---

104-105: Initialization encoding looks correct.
Ensures owner.addr is passed for proper ownership.

Reviewing files that changed from the base of the PR and between 5e76f55 and 368bedb.

• README.md (4 hunks)
• docs/btc-staking-e2e-testing.md (9 hunks)
• lib/create3-factory (1 hunks)
• script/10_DeployImuachainGatewayOnly.s.sol (1 hunks)
• script/deployments/deployedContracts.json (2 hunks)
• script/integration/1_DeployBootstrap.s.sol (11 hunks)

• lib/create3-factory
• script/10_DeployImuachainGatewayOnly.s.sol

• GitHub Check: test

README.md (5)

1-1: Repository title updated successfully
The shift from "Exocore" to "Imua" appears consistent with the overall rebranding effort.

---

3-3: Documentation consistency looks good
No issues found with references to "imua-contracts" in this line.

---

15-15: Confirm docs link validity
Please ensure that the link to https://docs.imua.xyz/components/smart-contracts points to the correct documentation location.

---

34-34: Clone command aligns with new repository
The updated clone URL is correct under the new branding.

---

72-76: Updated deployment addresses reference
The instructions to use main and script/deployments/deployedContracts.json ensure clarity on finding the latest contracts.

docs/btc-staking-e2e-testing.md (6)

19-19: Repository URL updated
Swapping to github.com/imua-xyz/esplora.git matches the new branding.

---

35-35: Faucet info block clarity
No issues found; the faucet reference is helpful for regtest usage.

---

45-47: Section heading and instructions updated
Renaming this section to "Start Imuachain Node" is consistent with the rebrand.

---

105-105: TODO notice
Acknowledging the comment about moving to imua-xyz; this is purely organizational.

---

139-139: Command reference updated
Directing users back to imua-contracts for E2E testing is correct.

---

154-154: Test scope looks comprehensive
Simulating BTC deposit and checking the staker's Imuachain balance is consistent with the rebranding in code.

script/deployments/deployedContracts.json (2)

5-15: Updated addresses in clientChain section
All updated addresses appear well-formed and conform to the rebrand. No issues found.

---

34-38: Imuachain section addition
Adding the new imuachain block is consistent with the removal of the exocore section elsewhere in the project.

script/integration/1_DeployBootstrap.s.sol (10)

24-26: Imports updated to ImuaCapsule
Renaming from ExoCapsule to ImuaCapsule is consistent with the proud new brand.

---

49-49: Verify chain ID usage
Using imuachainChainId = 1 could conflict with Ethereum mainnet. Confirm this is intentional or only for local tests.

---

68-68: Interface alignment
Switching to IImuaCapsule matches the new contract name.

---

205-207: ImmutableConfig updated
Replacing the references to Imua fields (e.g., imuachainChainId, imuaCapsuleBeacon) is consistent.

---

243-243: Documentation comment updated
No functional changes, just clarifying deposit params for ImuaCapsule.

---

296-298: Creating and logging ImuaCapsule
Implementation logic looks good.

---

303-309: Validators array renamed to “ims”
All references align well with the new im-style addresses.

---

330-330: Validator registration
Method call is correct under the new naming.

---

353-360: Delegations for validators
The loop logic is consistent with the updated references to ethToImAddress.

---

386-388: Staker delegation
The delegation approach is thoroughly consistent with the new brand references.